Table of Contents
List of Figures
List of Tables
The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.
NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.
In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.
NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.
This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.
The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].
DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.
HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.
LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.
Conformance Statements are critical to interoperability because they provide important information for implementers and system integrators in order to determine whether or not applications do interoperate. In addition, when issues occur, they provide a source of information in order to potentially resolve any problems. Lastly, it is important to provide potential implementers with a consistent template for generating these documents.
PS3.2 defines principles that implementations claiming conformance to the Standard shall follow. PS3.2 specifies:
the minimum general conformance requirements that must be met by any implementation claiming conformance to the DICOM Standard. Additional conformance requirements for particular features, Service Classes, Information Objects, and communications protocols may be found in the conformance sections of other Parts of the DICOM Standard;
the purpose and structure of a Conformance Statement. PS3.2 provides a framework by which conformance information can be placed into a Conformance Statement as dictated by the conformance sections of other Parts of the DICOM Standard.
The DICOM Standard does not specify:
testing or validation procedures to assess an implementation's conformance to the Standard;
testing or validation procedures to assess whether an implementation matches to its Conformance Statement;
what optional features, Service Classes, or Information Objects should be supported for a given type of device.
The following standards contain provisions, which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.
[ISO/IEC Directives, Part 2] 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .
[ISO 7498-1] 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
For the purposes of this Standard the following definitions apply.
This Part makes use of the following terms defined in [ISO 7498-1]:
See [ISO 7498-1].
See [ISO 7498-1].
See [ISO 7498-1].
See [ISO 7498-1].
This Part makes use of the following terms defined in [ISO 8649]:
See [ISO 8649].
See [ISO 8649].
This Part makes use of the following terms defined in [ISO 8822]:
See [ISO 8822].
See [ISO 8822].
See [ISO 8822].
See [ISO 8822].
This Part makes use of the following terms defined in PS3.1:
This Part makes use of the following terms defined in PS3.3:
This Part makes use of the following terms defined in PS3.4:
This Part makes use of the following terms defined in PS3.5:
This Part makes use of the following terms defined in PS3.7:
This Part makes use of the following terms defined in PS3.8:
This Part makes use of the following terms defined in PS3.10:
This Part uses the following definitions:
A SOP Class defined in the DICOM Standard that is used in an implementation with no modifications.
A SOP Class defined in the DICOM Standard extended in an implementation with additional Type 3 Attributes. The additional Attributes may either be drawn from the Data Dictionary in PS3.6, or may be Private Attributes. The semantics of the related Standard SOP Class shall not be modified by the additional Type 3 Attributes when absent. Therefore, the Standard Extended SOP Class utilizes the same UID as the related Standard SOP Class.
A SOP Class derived from a Standard SOP Class that has been specialized in an implementation by additional Type 1, 1C, 2, 2C, or 3 Attributes, by enumeration of specific permitted values for Attributes, or by enumeration of specific permitted Templates. The additional Attributes may either be drawn from the Data Dictionary in PS3.6, or may be Private Attributes. The enumeration of permitted Attribute values or Templates shall be a subset of those permitted in the related Standard SOP Class. Since the semantics of the related Standard SOP Class may be modified by the additional Attributes, a Specialized SOP Class utilizes a Privately Defined UID that differs from the UID for the related Standard SOP Class.
Since a Specialized SOP Class has a different UID than a Standard or Standard Extended SOP Class, other DICOM implementations may not recognize the Specialized SOP Class. Because of this limitation, a Specialized SOP Class should only be used when a Standard or Standard Extended SOP Class would not be appropriate. Before different implementations can exchange Instances in a Specialized SOP Class, the implementations must agree on the UID, content (in particular the additional Type 1, 1C, 2, and 2C Attributes), and semantics of the Specialized SOP Class. A Specialized SOP Class may be used to create a new or experimental SOP Class that is closely related to a Standard SOP Class.
The Association Negotiation for a Specialized SOP Class may include a SOP Class Common Extended Negotiation Sub-Item (as defined in PS3.7) for identification of the Service Class and of the Related General SOP Class from which it was specialized. This may allow a receiving application, without prior agreement on the Specialized SOP Class IOD, to process Instances of that class as if they were instances of a Related General SOP Class.
A SOP Class that is not defined in the DICOM Standard, but is published in an implementation's Conformance Statement.
Since a Private SOP Class is not defined in the DICOM Standard, other DICOM implementations may not recognize the Private SOP Class. Because of this limitation, a Private SOP Class should only be used when a Standard or Standard Extended SOP Class would not be appropriate. In order for different implementations to exchange Instances in a Private SOP Class, the implementations must agree on the UID, content (in particular the Type 1, 1C, 2, and 2C Attributes), and semantics of the Private SOP Class. A Private SOP Class may be used to create a totally new or experimental SOP Class.
An Attribute defined in the Data Dictionary in PS3.6.
An Application Profile defined in the DICOM Standard that is used in an implementation with no modifications.
An Application Profile derived from a Standard Application Profile by incorporating support for additional Standard or Standard Extended SOP Classes.
An Application Profile that is not defined in the DICOM Standard, but is published in an implementation's Conformance Statement.
A mechanism for selecting an appropriate set of choices from the Parts of the DICOM Standard along with corresponding security mechanisms (e.g., encryption algorithms) for the support of security facilities.
A mechanism for mapping and transforming DICOM SR objects to HL7 CDA documents.
This Part makes use of the following terms defined in PS3.18:
This Part makes use of the following terms defined in PS3.18
The following symbols and abbreviations are used in this Part.
Comite Europeen de Normalisation-Technical Committee 251-Medical Informatics
Japan Medical Imaging and Radiological Systems Industries Association
A RESTful Web service is a Web service implemented using REST architecture and HTTP (see http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf)
In a Conformance Statement, the relationships between Real-World Activities and Application Entities are illustrated by an Application Data Flow Diagram.
An Application Entity is depicted as a box in an Application Data Flow Diagram, shown in Figure 5.1-1
A Real-World Activity is depicted as a circle in an Application Data Flow Diagram, shown in Figure 5.1-2.
Circles representing multiple Real-World Activities may overlap, indicating a degree of overlap in the Real-World Activities.
A relationship between a local Real-World Activity and an Application Entity is depicted within an Application Data Flow Diagram by placing the local Real-World Activity to the left of the related Application Entity with a dashed line between them as shown in Figure 5.1-3.
An Application Entity may be associated with multiple Real-World Activities.
A Real-World Activity may be associated with multiple Application Entities.
An Association between a local Application Entity and a remote Application Entity over a network supporting a remote Real-World Activity is depicted within an Application Data Flow Diagram by placing the remote Real-World Activity to the right of the related local Application Entity with one or two arrows drawn between them as shown in Figure 5.1-4. The dashed line represents the DICOM Standard Interface, which could be DICOM DIMSE, DICOM Web Services or DICOM Real-Time Video, between the local Application Entities, and whichever remote Application Entities handle the remote Real-World Activities. An arrow from the remote Real-World Activity to the local Application Entity indicates that the local Application Entity expects to receive an Association request when the remote Real-World Activity occurs, causing the local Application Entity to perform the local Real-World Activity.
Application Entities exchanging information on media use the DICOM File Service as specified in PS3.10 for access to, or creation of, File-sets. This File Service provides operations that support three basic roles, which are File-set Creator (FSC), File-set Reader (FSR), and File-set Updater (FSU).
These roles are depicted on an Application Data Flow diagram by directional arrows placed between the local Application Entities and the DICOM Storage Media on which the roles are applied.
Figure 5.1-5 illustrates the three basic roles.
The local interactions shown on the left between a local Real-World activity and a local Application Entity are depicted by a dashed line. The arrows on the right represent access by the local Application Entity to a File-set on the DICOM Storage Medium. When an Application Entity supports several roles, this combination is depicted with multiple arrows corresponding to each of the roles. The dotted arrow symbolizes the removable nature of media for an interchange application.
An implementation need not employ all the optional components of the DICOM Standard. After meeting the minimum general requirements, a conformant DICOM implementation may utilize whatever SOP Classes, communications protocols, Media Storage Application Profiles, optional (Type 3) Attributes, codes and controlled terminology, etc., needed to accomplish its designed task.
In fact, it is expected that an implementation might only support the SOP Classes related to its Real World Activities. For example, a simple film digitizer may not support the SOP Classes for other imaging modalities since such support may not be required. On the other hand, a complex storage server might be required to support SOP Classes from multiple modalities in order to adequately function as a storage server. The choice of which components of the DICOM Standard are utilized by an implementation depends heavily on the intended application and is beyond the scope of this Standard.
In addition, the DICOM Standard allows an implementation to extend or specialize the DICOM defined SOP Classes, as well as define Private SOP Classes.
A Conformance Statement allows a user to determine which optional components of the DICOM Standard are supported by a particular implementation, and what additional extensions or specializations an implementation adds. By comparing the Conformance Statements from two different implementations, a knowledgeable user should be able to determine whether and to what extent communications might be supported between the two implementations.
The content of Conformance Statement uses a consistent structure regardless of whether the implementation supports a DIMSE interface, a DICOM Media Storage interface, a DICOM Web Service interface, DICOM Real-Time Video interface, or a combination thereof. A single Conformance Statement shall be provided with the appropriate sections filled in. Sections not relevant for the implementation shall be kept and marked as not applicable. Subsections of a section marked as not applicable need not be included in the Conformance Statement (see the template in Annex N).
A Conformance Statement is permitted to either consist of a single document file, or to be a main document file that references a number of annexes contained in one or more separate document files.
The first part of the Conformance Statement contains a DICOM Conformance Statement Overview, which is typically a short summary at the beginning of the document providing a high level description of the system. It should list the transfer capabilities, DIMSE Services, Media Services, DICOM Web Services and DICOM Real-Time Video Services, including their roles (SCU/SCP, FSC, FSR, etc.), and supported Transfer Syntaxes. This overview should also include a list of all Root Templates supported by the system.
A functional overview containing the Application Data Flow Diagram that shows all the Application Entities. It also shows how they relate to both local and remote Real-World Activities.
The Service and Interoperability description section of a Conformance Statement consists of the following major parts:
Provides a more detailed specification of each SOP Classes supported within the various services (Worklist, MPPS, Storage, Query/Retrieve, Print, etc.)
Provides for each SOP Class related to an Abstract Syntax, a list of any SOP options supported;
Provides a description of any extensions, specializations, and publicly disclosed privatizations in this implementation;
Provides a description of any implementation details that may be related to DICOM conformance or interoperability;
Provides a description of which codes and controlled terminology mechanisms are used.
The media storage section of a Conformance Statement consists of the following major parts:
a more detailed specification of each Application Entity listing the Media Storage Application Profiles supported, which outlines the policies with which it creates, reads, or updates File-sets on the media;
a description of any extensions, specializations, and publicly disclosed privatizations in this implementation such as Augmented or Private Application Profiles;
a description of any implementation details that may be related to DICOM conformance or interoperability;
a description of which codes and controlled terminology mechanisms are used.
The network and Media Communication Details section of a Conformance Statement consists of the following major parts:
An implementation claiming DICOM conformance may choose to support one or more of the following communication mechanisms:
Conformance to the DIMSE protocol (see Section 7.1.1 DIMSE Protocol Conformance Requirements)
Conformance to DICOM Web Services (see Section 7.1.2 DICOM Web Services Conformance Requirements)
Conformance to DICOM Media Storage (see Section 7.2 DICOM Media Interchange Conformance Requirements)
Conformance to the DICOM Real-Time Video (see Section 7.8 DICOM Real-Time Video Conformance Requirements)
An implementation claiming DIMSE network conformance shall:
Conformance to a Standard or Standard Extended SOP Class implies conformance to the related IOD outlined in PS3.3, the Data Elements defined in PS3.6, and the operations and notifications defined in PS3.7.
comply with the rules governing SOP Class types outlined in Section 7.3;
accept a Presentation Context for the Verification SOP Class as an SCP if the implementation accepts any DICOM Association requests;
produce and/or process Data Sets as defined in PS3.5;
An implementation claiming DICOM Web Services conformance shall:
conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;
conform to at least one Service as defined in PS3.18;
comply with the rules governing SOP Class types outlined in Section 7.3;
produce and/or process Data Sets as defined in PS3.5 and/or PS3.18;
obtain a legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).
An implementation claiming DICOM Media Interchange conformance shall:
conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;
conform to at least one Standard Application Profile as defined in PS3.11;
support one of the Physical Media and associated Media Format, as specified by PS3.12;
comply with the rules governing SOP Class types outlined in Section 7.3;
comply with the specific rules governing media storage Application Profile according to their types as specified in Section 7.4. No other types of Application Profiles may be used;
read as an FSR or FSU all SOP Classes defined as mandatory by each of the supported Application Profiles encoded in any of the mandatory Transfer Syntaxes.
write as an FSC or FSU all SOP Classes defined as mandatory by each of the supported Application Profiles in one of the mandatory Transfer Syntaxes;
be able to gracefully ignore any Standard, Standard Extended, Specialized or Private SOP Classes that may be present on the Storage Medium but are not defined in any of the Application Profiles to which conformance is claimed.
There may be more than one Application Profile used to create or read a File-set on a single physical medium (e.g., a medium may have a File-set created with Standard and Augmented Application Profiles).
be able to gracefully ignore Directory Records in the DICOMDIR file that do not correspond to Directory Records defined in any of the Application Profiles to which conformance is claimed.
access the File-set(s) on media using the standard roles defined in PS3.10;
produce and/or process Data Sets as defined in PS3.5 encapsulated in DICOM Files;
obtain legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).
An implementation that does not meet all the above requirements shall not claim conformance to DICOM for Media Storage Interchange.
Each SOP Class published in a Conformance Statement is one of four basic types. Each SOP Class in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of SOP Class.
Standard SOP Classes conform to all relevant Parts of the DICOM Standard with no additions or changes.
To claim conformance to a Standard SOP Class, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.
Standard Extended SOP Classes shall:
not change the semantics of any Standard Attribute of that Standard SOP Class;
not contain any Private Type 1, 1C, 2, or 2C Attributes, nor add additional Standard Type 1, 1C, 2 or 2C Attributes;
not change any Standard Type 3 Attributes to Type 1, 1C, 2, or 2C;
use the same UID as the Standard SOP Class on which it is based.
A Standard Extended SOP Class may include Standard and/or Private Type 3 Attributes beyond those defined in the IOD on which it is based as long as the Conformance Statement identifies the added Attributes and defines their relationship with the PS3.3 information model. If additional Type 3 Attributes drawn from the Data Dictionary in PS3.6 are sent that affect the encoding of other Attributes, or whose encoding depends on the values of other Attributes, their presence and use shall be consistent.
E.g., An Attribute such as Pixel Padding Value (0028,0120) with a dictionary VR of US or SS would not be allowed to be present without Pixel Representation (0028,0103) also being present to resolve the encoding ambiguity. Further, Pixel Padding Value would not be allowed to be present in the absence of the Pixel Data (7FE0,0010) to which it applies.
An implementation claiming conformance with a Standard Extended SOP Class shall identify in its Conformance Statement the Standard SOP Class being extended, the options, roles, and behavior selected, and describe the Attributes being added with the Standard SOP Class's IOD Model and Modules.
Specialized SOP Classes shall:
contain additional Standard and/or Private Type 1, 1C, 2, or 2C Attributes;
add Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.
enumerate the permitted values for Attributes within the set allowed by the Standard SOP Class;
enumerate the permitted Templates for Content Items within the set allowed by the Standard SOP Class.
An implementation claiming conformance with a Specialized SOP Class shall include in its Conformance Statement the identity of the Standard SOP Class being specialized, a description of usage of all Standard and Private Type 1, 1C, 2, and 2C Attributes in the Specialized SOP Class, a description of the constraints on Attributes values and Templates, and the associated Privately Defined UID.
be completely conformant to relevant Parts of the DICOM Standard with the possible exception that support of the DICOM Default Transfer Syntax or a Transfer Syntax mandated by a media storage Application Profile is not required;
not change the PS3.6 specification of any Standard Attributes;
use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);
not change existing DICOM File Services defined in PS3.10 or extend them in a manner that jeopardizes interoperability.
use or apply DIMSE Services to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);
use or apply Media Storage Operations to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);
designate any Standard Attribute as Type 1, 1C, 2, or 2C regardless of the Type of the Attribute in other IODs;
include Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.
An implementation claiming conformance with a Private SOP Class shall provide a PS3.3, PS3.4, and PS3.6-like description of the Private SOP Class in the implementation's Conformance Statement, including descriptions of the usage of all Standard and Private Type 1, 1C, 2, or 2C Attributes in the SOP Class, the DICOM Information Model, and the Privately Defined UIDs.
Unpublished SOP Classes (i.e., SOP Classes that are not defined in the DICOM Standard and are not defined in the Conformance Statement) are permitted in order to allow an implementation to support other abstract syntaxes within the DICOM Application Context. Such unpublished SOP Classes would utilize Privately Defined UIDs. The presence of an unpublished SOP Class does not prevent the implementation from being DICOM conformant but would have no meaning to other implementations and may be ignored.
Application Profile used in a Conformance Statement shall be of one of three basic types. Each Application Profile in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of Application Profile.
A Standard Application Profile shall:
support only one of the Physical Media and associated Media Format, as specified by PS3.12.
To claim conformance to a Standard Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.
An implementation of a Standard Application Profile may extend Standard SOP Classes of this Standard application profile. Such Standard Extended SOP Classes shall meet the requirements specified in Section 7.3.
An Augmented Application Profile shall:
An Augmented Application Profile may:
include one or more Standard or Standard Extended SOP Classes in addition to those of the corresponding Standard Application Profile. These additional SOP Classes may be mandatory or optional;
include the extensions (e.g., additional required keys, additional directory records) to the Basic Directory Information Object corresponding to the SOP Classes defined in a);
To claim conformance to an Augmented Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and shall identify the Standard Application Profile from which it is derived and specify the augmentations. The implementation shall also identify its selected options, roles, and behavior.
An implementation of a Augmented Application Profile may:
extend Standard SOP Classes of the corresponding Standard application profile. Such Standard Extended SOP Classes shall meet the requirements specified in Section 7.3;
also claim conformance to the Standard Application Profile on which this Augmented Profile is based. In this case, FSC and FSU implementations shall be able to restrict their behavior to the Standard Application Profile (i.e., provide a means to write only the Standard or Standard Extended SOP Classes defined in the corresponding Standard Application Profile).
A Private Application Profile:
conforms to PS3.10 and to the Media Storage Service Class specified in PS3.4;
support only one of the Physical Media and associated Media Format, as specified by PS3.12;
complies with the rules governing SOP Classes in Section 7.3.
To claim conformance to a Private Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and shall provide a description of the Application Profile patterned after the descriptions in PS3.11. The implementation shall also identify its selected options, roles, and behavior.
An implementation that does not meet the provisions of Section 7, including the types of Application Profile, is not conformant to DICOM and so is outside the scope of DICOM conformance. Such an implementation is not an Application Profile in DICOM terminology. For example, if an implementation chooses to write DICOM files onto media that is not in PS3.12, or use a file system not defined for a specific media type in PS3.12, then that implementation cannot claim that it conforms to the DICOM Standard using that media or file system.
DICOM does not define conformance of a piece of medium in a generic sense. DICOM conformance of a piece of medium can only be evaluated within the scope of one or more media storage Application Profiles that define specific contexts for interoperability.
DICOM specifies methods for providing security at different levels of the ISO OSI Basic Reference Model through the use of mechanisms specific to a particular layer. The methods for applying these mechanisms are described in the various parts of the DICOM Standard. Some mechanisms and algorithms are specified in PS3.15 as Security Profiles. An implementation's Conformance Statement describes which Security Profiles can be used by that application.
For example, the Basic TLS Secure Transport Connection Profile defines a mechanism for authenticating entities participating in the exchange of data, and for protecting the integrity and confidentiality of information during interchange.
An implementation shall list in its Conformance Statement any Security Profiles that it supports, how it selects which Security Profiles it uses, how it uses features of that Security Profile, and any extensions it makes to that Security Profile.
An implementation shall list in its Conformance Statement any additional use of the User Identity Association negotiation sub-item that is not specified in a standard Security Profile.
DICOM specifies the transformation of DICOM SR objects to CDA documents in PS3.20.
This transformation is unidirectional (DICOM SR to HL7 CDA). Conformance statements shall at a minimum state conformance to the top level templates used for the SR document and the CDA document.
An implementation claiming DICOM Real-Time Video conformance shall:
conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;
conform to at least one Service as defined PS3.22;
comply with the rules governing SOP Class types outlined in Section 7.3;
produce and/or process Data Sets as defined in PS3.5 and/or PS3.22;
obtain a legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
Retired. See PS3.2-2022d
This Annex provides a template for a DICOM Conformance Statement. For convenience a Microsoft Word version of this template can be found at: http://www.dicomstandard.org/resources/templates
This Annex defines the normative content of a DICOM Conformance Statement. Changes to this Annex may not be immediately reflected in the Microsoft Word version of this template. When the current release of DICOM PS3.2 and the Microsoft Word version of this template do not match, it is the responsibility of the editor of a DICOM Conformance Statement to ensure the correct current content is reflected in the created DICOM Conformance Statement.
The content and organization of DICOM Conformance Statements shall conform to this template.
The following formatting conventions are used in this template to guide Conformance Statement authors. Based on the format of the text used in the template, a DICOM Conformance Statement shall:
Include, without modification, text shown in regular font style (i.e., non-italic). Such text is standard "boilerplate" like introductions to sections, tables that list mandatory Attributes, etc.
Remove text shown in italic font style and [enclosed by square brackets]. Such text provides instructions to Conformance Statement authors on how to use this template. The text may be retained until the author has no further use for it but should be removed before publication of the Conformance Statement.
Either remove text shown in italic font style or modify it appropriately and change it to regular font style. Such text is example text that may provide typical phrasing, examples of the types of topics that might be addressed in a certain section, or list optional Attributes which should be deleted if not supported, etc.
Replace text <enclosed in angle brackets> with appropriate text. Such text is a placeholder for variables like the product name. Remove the < > characters when replacing the text.
Replace text <<enclosed in double angle brackets>> with a single Value from the enclosed list. Such text provides a list of alternatives such as DICOM Defined Terms for an Attribute Value. Remove the << >> characters when replacing the text.
If Values other than those listed may be used, that is indicated by an ellipsis before the closing angle brackets (i.e., "…>>")
If multiple Values can be selected, instruction text will document that fact.
If some of the multiple Values are mandatory, the mandatory Values are shown in regular font style and the optional Values are shown in italic font style.
Some sections and tables mix text in multiple fonts. Each piece of text is treated accordingly to its font style.
The following conventions are used in this template to encourage uniformity that makes it easier for consumers to read Conformance Statements from different vendors and find specific pieces of information. A DICOM Conformance Statement shall:
Indicate support in tables (e.g., in the "SCU" and "SCP" column of table with rows for SOP Classes) by using "Y" for yes and "N" for no.
Include rows in tables only for things (e.g., SOP Classes, Services, Attributes, etc.) supported by your implementation. Do not include rows for things that are not supported.
Format supported Value ranges in table cells using square brackets as follows: [lower Value … upper Value].
Format multiple supported Values in table cells separated by a semicolon in the cell.
Replace the content of Sections that are not applicable to the implementation with the text "N/A" and append "- N/A" to the end of the section title. This is done rather than deleting the section; however, if all the subsections in a section are marked "N/A", the subsections may be deleted, and, if so, the parent section should have the text "N/A" as content, and its title should have "- N/A" appended to its original title. This keeps the numbering of sections consistent throughout DICOM Conformance Statements for easier comparison.
If Sections need to be added, append them at the end of the parent Section in order to keep Section numbering consistent with this template.
Tables shall be numbered sequentially within each major subsection. It is not necessary to follow the table numbering in the template, if specific tables are not applicable for the product described in this DICOM Conformance Statement.
Consider providing information (e.g., extensive explanation) as a footnote under the table when the information exceeds the comfortable size of the cell.
The Annexes are mandatory parts of this template and shall be populated if applicable to the implementation. For example, the IOD definitions must be filled in if the implementation supports creation of DICOM SOP Instances.
If throughout the document any of the tables get too wide for portrait mode it is recommended to switch to landscape mode for the table.
Tables are split into subsections for better readability. If a subsection of the table is not supported, remove the complete subsection from the table.
If the DICOM Conformance Statement describes multiple products/versions in one document, the cover page should indicate which products/versions are covered.
Ensure spelling throughout the entire DICOM Conformance Statement is consistent with the DICOM Standard.
If this template contradicts normative statements in other Parts of the DICOM Standard, those other Parts take precedence.
The template content begins after this line.
[When using this template for creation of a DICOM Conformance Statement, start numbering the actual document content with Section 1 for the Overview, not with N.1.]
[Provide a short description of the product's DICOM functionality.]
[Edit the following illustration, depicting DICOM Services implemented in your product and the interactions with remote systems connected to product. Replace <Product> with your product name and <Remote Systems x> with a system category such as modality, PACS, RIS, or <DICOM Service> by the applicable service such as storage, query/ retrieve, query modality worklist, ….]
Table N.1-1 lists all Storage SOP Classes and the supported transfer mechanisms as well as the usage scenarios for those instances.
The "Transfer Syntax Set" column lists the sets of Transfer Syntaxes defined in Table N.1-2 that are applicable to each SOP Class. The "DIMSE", "DICOM Web" and "Media Services" columns indicate the roles supported for each SOP Class.
The "Function" columns indicate how the instances are used by the system:
Create: The system creates instances of the SOP Class. The type of the created SOP Class is indicated by one of the following abbreviations:
Display: The system displays the instances of the SOP Class to the user, either by displaying the SOP Instances natively or by applying instances of another suitable SOP Class to the image instances (e.g., a Presentation State or CAD SR).
Process: The system processes the instances of the SOP Class to derive some further information that is made available to the user (e.g., a CAD processing algorithm, or a 3D Rendering).
Archive: The system stores the instances of the SOP Class and makes them available again.
[List all Storage SOP Classes supported by the system in numerical order of the SOP Class UID. Indicate in the "Transfer Syntax Set" column which of the Transfer Syntax Sets defined in Table N.1-2 are supported. Note that for each SOP Class, multiple Transfer Syntax Sets can be supported.]
[For the "Create Function" columns, use Values as defined above. For all other supported role/"Function" columns, list "Y" for yes and "N" for no.]
[Table N.1-2 defines some example Transfer Syntax Sets that are referenced by their abbreviation in Table N.1-1 above. You can modify the Transfer Syntax Sets to match your product implementation and extend the Table with additional Transfer Syntax Sets as needed. For additional Transfer Syntax Sets, create additional rows and assign abbreviations in "() " that can be referenced in the Table above.]
Table N.1-2. Supported Transfer Syntaxes
Table N.1-3 lists all Template IDs (TID) of Root Templates that are supported by the system. The "Function" column indicates how the system uses the content of the DICOM SR:
CREATE: The system creates instances using the specified TID.
RENDER: The system displays the content of the SR, without using the data for any processing.
EXTRACT_DATA: The system can extract structured data from the content and use the data for subsequent processing (e.g., reporting).
OVERLAY: The system uses the information in the SR to display information directly on the images (e.g., Mammography CAD markers).
The "SOP Class UID" column indicates which of the SR Storage SOP Classes are used to encode the information or to store it. If multiple SOP Classes are supported the "Condition" column describes the conditions for using the different SOP Classes.
[Table N.1-3 provides some examples, add/remove TIDs to match your product implementation. Add Root TIDs in ascending numerical order.
For guidance on the meaning of the columns see description above. Note that in the "Function" column multiple Values can be listed.
It is recommended to add a link to the "Root Template ID" column to the relevant subsection of Section N.10.]
Table N.1-4 lists support for the Verification SOP Class.
[Modify Table N.1-4 to reflect support for the Verification SOP Class.]
For details on supported Storage SOP Classes see Section N.1.1.
Table N.1-5 lists all supported Workflow Management SOP Classes.
[Modify Table N.1-5 to reflect SOP Classes in the Workflow Management area that are supported. For each supported service indicate the role it supports. If it neither supports a SOP Class as SCU nor SCP, remove the respective line from the Table]
Table N.1-6 lists all supported Query/Retrieve SOP Classes.
[Table N.1-6 lists some SOP Classes for querying and retrieving from a remote DICOM node, nevertheless PS3.4 defines many more additional SOP Classes for querying and retrieving. If your product supports any of these additional SOP Classes (e.g., any of the SOP Classes supporting C-GET), add them to Table N.1-6 and delete the SOP Classes not supported by your product. If you neither support a SOP Class as SCU or SCP, remove the respective line from Table N.1-6.]
Table N.1-7 lists all supported Printing SOP Classes.
[Table N.1-7 lists some SOP Classes for Printing and PS3.4 defines additional SOP Classes for printing. If your product supports any of these additional SOP Classes, add them to Table N.1-7, and remove any rows that do not apply to your product. If you neither support a SOP Class as SCU nor SCP, remove the respective line from Table N.1-7.]
Table N.1-8 lists details on the support of the URI Service.
[Complete Table N.1-8 to indicate support for the URI Web Service.]
For resources supported see Table N.1-1 in Section N.1.1
Table N.1-9 lists details on the support of the Studies Service.
[Complete Table N.1-9 to indicate support for the Studies Web Service]
[If your Origin Server supports any Rendered MPR Volume Resources or Rendered 3D Volume Resources, indicate supported SOP Classes in the “Process” column of Table N.1-1.]
Table N.1-10 lists details on the support of the Worklist Service.
[Complete Table N.1-10 to indicate support for the Worklist Web Service.]
Table N.1-11 lists details on the support of Non-Patient Instances Service.
For details on the supported resource categories (e.g., Color Palette, Defined Procedure Protocol, Hanging Protocol or Implant Templates), see Table N.1-1.
[Complete Table N.1-11 to indicate support for the Non-Patient Instance Web Service.]
Table N.1.3.5-1 lists details on the support of the Storage Commitment Service.
[Complete Table N.1.3.5-1 to indicate support for the Storage Commitment Web Service.]
Table N.1-12 lists all supported Media Application Profiles.
[Table N.1-12 lists Media Storage Application profiles and supported roles. Extend/modify the Table to list the profiles supported by your system.]
Table N.1-13 lists all supported Real-Time Video SOP Classes and Transfer Syntaxes.
[List all supported Real-Time Video SOP Classes in Table N.1-13. For the "Transfer Syntax Set" column use Transfer Syntax Sets defined in Table N.1-2.]
Table N.1-14 lists all supported de-identification profiles and options.
[Complete Table N.1-14 to list supported De-Identification profiles and options. If you do not support de-identification, remove this table, and mark section as N/A]
[List all supported Character Sets and the IANA name as well as a description in Table N.1-15.]
[The Table of Contents shall be provided to assist readers in easily finding the needed information.]
[Provide the revision history for this document including the document revision, the document revision date, the product version(s) the DICOM Conformance Statement applies to and give a high-level description of changes.]
This document is intended for the audience listed below. It is assumed that the reader has a working knowledge of the DICOM Standard.
[Below is a list of typical users of a DICOM Conformance Statement, modify and add other user groups if needed.]
The document structure was designed for easier access to relevant information for different user groups:
Clinical Users, who want to get an overview of the implemented interoperability features of the system can see Section N.4 Implementation Model.
Personnel involved in Sales can use the information in Section N.1 to assess the compatibility between different systems involved in a sales situation.
System Integrators can use information in Section N.6 during system installation and also information from Section N.5 Service and Interoperability Description for details regarding the implemented services.
Field Service Engineers can use the details from Section N.5 Service and Interoperability Description and from Section N.7 Network and Media Communication Details for troubleshooting.
Hospital IT staff focusing on security can use the details provided in Section N.8 Security regarding implemented Security features.
Research Personnel may be interested in using information provided in Section N.9 Information Object Definitions (IODs) or Section N.10 Structured Report Content Encoding to get detailed imaging and measurement information.
[Any important remarks, disclaimers, and general information are specified. The following example may be used as a template.]
The scope of this DICOM Conformance Statement is to facilitate integration between < Product> and other DICOM products. The Conformance Statement should be read and understood in conjunction with the DICOM Standard [1]. DICOM by itself does not guarantee interoperability.
The Conformance Statement does, however, facilitate a first-level comparison for interoperability between different applications supporting compatible DICOM functionality.
This Conformance Statement should not replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, it is the user's responsibility to perform the following validation activities:
The comparison of Conformance Statements from <Product> and other DICOM conformant equipment is the first step towards assessing interconnectivity and interoperability between those systems.
Test procedures should be defined and executed to validate the required level of interoperability with specific DICOM conformant equipment, as established by the healthcare facility.
[If the product has an IHE Integration Statement, the following statement may be applicable]:
<Product> has participated in an industry-wide testing program sponsored by Integrating the Healthcare Enterprise (IHE). The IHE Integration Statement of <Product> together with the IHE Technical Framework may facilitate the process of validation testing.
[Terms and definitions should be listed here. The following list includes DICOM terms, delete terms that are not used throughout the Conformance Statement, but do not add or modify terms listed here.]
The following list includes DICOM Terms, that are used throughout this Conformance Statement:
|
The information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) Class. Examples: Verification SOP Class, Modality Worklist Information Model Find SOP Class, Computed Radiography Image Storage SOP Class. |
|
|
A representation of the external behavior of an application process in terms of DICOM Network Services, Web Services and/or media exchange capabilities implemented in one or more roles. A single device may have multiple Application Entities. |
|
|
The externally known name of an Application Entity, used to identify a DICOM application to other DICOM applications on the network. |
|
|
The specification of the type of communication used between Application Entities. Example: DICOM network protocol. |
|
|
A network communication channel set up between Application Entities. |
|
|
A unit of information in an Information Object Definition; a Data Element identified by a tag. The information may be a complex data structure (Sequence), itself composed of lower-level data elements. Examples: Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation (0028,0004), Procedure Code Sequence (0008,1032). |
|
|
A unit of information as defined by a single entry in the data dictionary. An encoded Information Object Definition (IOD) Attribute that is composed of, at a minimum, three fields: a Data Element Tag, a Value Length, and a Value Field. For some specific Transfer Syntaxes, a Data Element also contains a VR Field where the Value Representation of that Data Element is specified explicitly |
|
|
The specified set of Attributes that comprise a type of data object; does not represent a specific instance of the data object, but rather a class of similar data objects that have the same properties. Examples: MR Image IOD, CT Image IOD, Print Job IOD. The Attributes within an IOD may be specified as Mandatory (Type 1), Required but possibly unknown (Type 2), or Optional (Type 3), and there may be conditions associated with the use of an Attribute (Types 1C and 2C). |
|
|
The specification of DICOM information objects and encoding exchanged on removable media (e.g., CDs). |
|
|
A set of Attributes within an Information Object Definition that are logically related to each other. Example: Patient Module includes Patient's Name, Patient ID, Patient' Birth Date, and Patient's Sex. |
|
|
First phase of Association establishment that allows Application Entities to agree on the types of data to be exchanged and how that data will be encoded. |
|
|
Refers to the program that can originate authoritative responses to HTTP requests for a given Target Resource. The term "server" refers to any implementation that receives a web service request message from a user agent. |
|
|
The set of DICOM Network Services used over an Association, as negotiated between Application Entities; includes Abstract Syntaxes and Transfer Syntaxes. |
|
|
A SOP Class that is not defined in the DICOM Standard but is published in an implementation's Conformance Statement. |
|
|
A packet (piece) of a DICOM message sent across the network. Devices must specify the maximum size packet they can receive for DICOM messages. |
|
|
A set of mechanisms, such as encryption, user authentication, or digital signatures, used by an Application Entity to ensure confidentiality, integrity, and/or availability of exchanged DICOM data. |
|
|
Role of an Application Entity that provides a DICOM network service; typically, a server that performs operations requested by another Application Entity (Service Class User). Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP). |
|
|
Role of an Application Entity that uses a DICOM Network Service; typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU). |
|
|
The specification of the network or media transfer (service) of a particular type of data (object) ; the fundamental unit of a DICOM interoperability specification. Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management. |
|
|
An information object; a specific occurrence of information exchanged in a SOP Class. E.g., a specific X-ray image. |
|
|
A SOP Class that is derived from the Standard that is specialized by additional type 1, 1C, 2, 2C, or 3 Attributes, by enumeration of specific permitted Values for Attributes, or by enumeration of specific permitted Templates. The additional Attributes may either be drawn from the Data Dictionary in PS3.6 or may be Private Attributes. |
|
|
A SOP Class defined in the Standard, and that is implemented and used without any modifications. |
|
|
A SOP Class that is defined in the standard, and that is extended by additional type 3 Attributes. The additional Attributes may either be drawn from the DICOM Data Dictionary in PS3.6 or may be Private Attributes. |
|
|
A 32-bit identifier for a Data Element, represented as a pair of four-digit hexadecimal numbers, the "group" and the "element". If the "group" number is odd, the tag is for a private (manufacturer-specific) data element. Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element]. |
|
|
The encoding used for exchange of DICOM information objects and messages. Examples: JPEG compressed (images), Little Endian Explicit Value Representation. |
|
|
TCP port on which an implementation accepts TLS connections to exchange DICOM information. |
|
|
A globally unique "dotted decimal" string that identifies a specific object or a class of objects; an ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOP Instance UID. |
|
|
A client in a network protocol used in communications within a client-server distributed computing system. In particular, the Hypertext Transfer Protocol (HTTP) identifies the client software originating the request, using a user-agent header, even when the client is not operated by a user. |
|
|
The format type of an individual DICOM data element, such as text, an integer, a person's name, or a code. DICOM information objects can be transmitted with either explicit identification of the type of each data element (Explicit VR), or without explicit identification (Implicit VR) ; with Implicit VR, the receiving application must use a DICOM data dictionary to look up the format of each data element. |
[Modify: Add a list of product specific definitions here. If none are needed remove the following introduction and table]
The following list includes product specific definitions used throughout this Conformance Statement
Abbreviations that are used in this DICOM Conformance Statement are listed here.
[It is important to add any additional terms used by the implementation. Terms in the list may also be deleted at the discretion of the implementer.]
[Referenced documents should be listed here, including appropriate product manuals (such as service manuals that specify how to set DICOM communication parameters). References to the DICOM Standard should provide the URL for the free published version of the Standard, but should not specify a date of publication]:
[1] PS3 / ISO 12052 Digital Imaging and Communications in Medicine (DICOM) Standard. http://www.dicomstandard.org .
[2] IHE Radiology Technical Framework. http://www.ihe.net/Resources/technical_frameworks/#radiology .
[Provide a short description of your implementation, including list of product names and versions that this DICOM Conformance Statement (DCS) intends to cover, as well as the use of DICOM Networking, DICOM Media Interchange and DICOM Web Services to achieve their purpose.]
[Also provide some high-level details of your product architecture, which are relevant to the interoperability features of the product (e.g., implementation of functionality in separate applications).]
The network and media interchange application model for the < Product> is shown in Figure N.4-1 <Product> Application Data Flow Diagram.
[Edit the Application Data Flow Diagram and description below as appropriate. Note that the Real-World Activity and Application Entity names specified in the figure must be used consistently throughout the document. If your product supports configurable AE definition, then describe the default configuration of AEs in this section. As a reminder, an AE is a representation of the external behavior of an application process in terms of DICOM network services, web services and/or media exchange capabilities implemented in one or more roles. A single device may have multiple Application Entities.]
[For each AE listed in Figure N.4-1 add one subsection A.4.1.x to describe the AE's DICOM functionality with regards to supported DIMSE, DICOM Web and Media Services, including the real-world activities that may trigger the service.]
[If your system supports flexible grouping of Services into Application Entities, keep the following paragraph, otherwise delete it]
This section describes the organization of the supported Services into Application Entities based on the default configuration of the system. This may change based on the actual setup at the customer site. See Section N.6 for details about the configurability of Services into AEs.
Table N.5-1 provides an overview of the Application Entities and the Services supported by each AE.
[Table N.5-1 provides the mapping between Application Entities, Services and Roles as indicated in the example below.]
[If needed, explain specific behavior of an AE in a note, e.g., if you have an AE that provides specifically storage of de-identified instances or support for querying rejected instances as defined in the IOCM profile, e.g.:
This implementation of Query/Retrieve service handles retrieval of rejected instances as defined in the IHE Radiology IOCM Profile [2].
[The following sections define the details of the supported DIMSE Services in more details. Fill in the information for all services supported by the system. Tables are given as examples and should be modified to meet the functionality of the system.]
As a Service Class User of the Modality Worklist Information Model - FIND SOP Class, the <Product> uses the C-FIND-RQ message to query the SCP. It supports the Query Keys listed in Table N.5-2.
In the "Matching Type" column, the following Values can be used:
SINGLE_VALUE: SCU can request single Value matching on this Attribute.
UID: SCU can request List of UID matching on this Attribute.
WILDCARD: SCU can request Wildcard matching on this Attribute.
SEQUENCE: SCU can request sequence matching on this Attribute.
UNIVERSAL: SCU can request that the Attribute be a return Value (universal matching).
In the "Query Value Source" column, the following Values can be used:
FIXED: The query Value cannot be modified by the user or by configuration.
GENERATED: The query Value is generated by the system (e.g., current date as the study date).
CONFIGURATION: The query Value is dependent on system configuration.
SCANNED: The query Value is read from a barcode scanner or similar device.
EMPTY: The query Value is sent with a zero-length Value to indicate it is a return key only.
In the "Display on UI" column the following Values can be used:
[Modify the Table N.5-2 to include all Attributes supported by your system and use the terms defined for Matching Type, Query Value Source and Display on UI above. If Display on UI Values are modified from the ones received, indicate in a footnote. If multiple Values are supported for the Query Value Source, list all of them.]
[Describe scenarios in which the product can issue C-FIND-CANCEL Requests, e.g.,
The product issues C-FIND CANCEL requests in the following scenarios:* Configurable maximum of matches detected* Initiated by user]
[Also describe the SCU behavior if the cancellation request is ignored by the SCP and the SCP continues sending responses.]
[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN), e.g.:
When configured for Japanese character set support, Person Name query attributes may contain ideographic (kanji) and/or phonetic (hiragana and katakana) and/or Romanized (romaji) representations.
When configured for Chinese character set support, Person Name query attributes may contain ideographic (hanzi) and/or phonetic (pinyin) representations are supported. For Patient’s Name (0010,0010), the representation which is displayed by default in the worklist is configurable.
When configured for Korean character set support, Person Name query attributes may contain ideographic (hanja) and/or phonetic (hangul) and/or Romanized representations.
If the product receives from the SCP a C-FIND response containing unsupported values in Specific Character Set (0008,0005), characters in that character set will be treated as unknown characters as described in Section 6.1.2.3 in PS3.5 .
If a Person Name attribute contains multiple representations, the GUI will display one representation based on a configurable order of preference.]
As a Service Class Provider of the Modality Worklist Information Model - FIND SOP Class, the <Product> uses the C-FIND-RSP to communicate matches back to the SCU. It supports the Matching Keys listed in Table N.5-3.
In the "Matching Type" column, the following Values can be used:
SINGLE_VALUE: SCP can perform single Value matching on this Attribute.
UID: SCP can perform List of UID matching on this Attribute.
WILDCARD: SCP can perform Wildcard matching on this Attribute.
SEQUENCE: SCP can perform sequence matching on this Attribute.
UNIVERSAL: SCP can provide the Attribute in the C-FIND response (i.e., universal matching).
[Table N.5-3 contains a set of Attributes that could be supported by a product. Add and remove Attributes in order to match your product implementation using the matching type as defined above. If multiple codes are supported, list all of them. Use the "Comments" column if clarification is needed.]
[Describe the behavior of the product when it receives a C-FIND-CANCEL Request.]
[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN), e.g.:
If the product receives from the SCU a Request Identifier containing unsupported values in the Specific Character Set (0008,0005), then no matching is performed and an error will be returned indicating the SCP is unable to process the request.]
[Document your product's query capabilities and behavior for handling implementation-dependent matching of VRs, such as for DA, DT, TM, IS and DS.]
As a Service Class User of the Modality Performed Procedure Step SOP Class, the <Product> supports the Attributes listed in Table N.5-4 in the N-CREATE-RQ and N-SET-RQ messages, if it creates the message.
In the "Source" column the following Values can be used:
[List all Attributes provided in the MPPS message and list the Values that are used to populate the N-CREATE or N-SET messages, add or remove Attributes as applicable for your product and note that in the "Source" column, multiple Values can be provided in a semicolon separated list.]
Table N.5-4. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCU
[Describe the triggers by which your product initiates sending messages, e.g., the N-CREATE is sent when starting image acquisition and N-SET is sent when the study is closed.]
[If product also supports forwarding of MPPS messages (e.g., as described by the MPPS Manager Actor in the IHE Schedule Workflow profile), provide a description of the product behavior here.]
As a Service Class Provider of the Modality Performed Procedure Step SOP Class, the product receives N-CREATE-RQ and N-SET-RQ messages from a remote SCU indicating the status of a procedure.
[Indicate in Table N.5-5 whether your product has specific requirements with regards to the message content, e.g., whether specific Attributes are required using Y for yes and N for no.]
Table N.5-5 lists the message content that is required.
Table N.5-5. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCP
[Describe the behavior of the product upon receiving an MPPS message, both the N-CREATE and the N SET.]
[If your product supports any of the Unified Worklist SOP Classes, list the supported SOP Classes, the role, a list of supported messages, and the content of each supported message. If one or more of the Unified Worklist SOP Classes are not supported, keep the section, but include text indicating the SOP Class is "N/A".]
As a Service Class User of the Instance Availability Notification SOP Class, the system uses the N-CREATE-RQ message to inform remote SCPs about the availability and status of instances stored. Details of the message content are summarized in Table N.5-6.
In the "Source" column the following Values can be used:
[Table N.5-6 lists some Attribute for instance availability notification as examples. Complete table with Attributes supported by your product. For the "Source" column use Values as defined above.]
Table N.5-6. Supported N-CREATE Attributes for Instance Availability Notification - SCU
|
See Table N.5-7 |
||||
The <Product> supports the Values listed in Table N.5-7, for the Instance Availability (0018,0056) Attribute.
[Fill in Table N.5-7 with Values supported for the Instance Availability Attribute and define the meaning of these Values in the context of your <Product>]
[Describe the mechanism that triggers sending of an Instance Availability Notification, the frequency and retrieve capabilities for referenced instances.]
[Describe the relationship between the Instance Availability Notification and Performed Procedure Step SOP Class, if both are supported.]
As a Service Class Provider of the Instance Availability Notification SOP Class, the system receives the N-CREATE-RQ message containing information on the availability and status of instances stored.
Table N.5-8 describes the behavior of <Product> when encountering one of the following Values for the Instance Availability (0018,0056) Attribute.
[Fill in the table with Values supported for the Instance Availability Attribute and define the policies of the product upon encountering these Values.]
[Describe the relationship between the Instance Availability Notification and Performed Procedure Step SOP Class, if both are supported and if a relationship exists.]
As a Service Class User of the Storage Service Class, the <Product> uses the C-STORE-RQ message to request storage of DICOM objects by a remote SCP. See Section N.1.1 Content and Transfer in the Overview for the list of supported SOP Classes.
For details regarding the content of SOP Instances that are created by the system, see Section N.9, which describes the underlying IOD of the supported SOP Classes.
[Provide some details regarding the triggering of storage requests (e.g., automatically when an instance is stored, automatically when the study is closed, or initiated by the user).]
[Describe when and how your product divides sets of instances into multiple series and or studies and how these are ordered.]
[Describe the behavior of your product in the case of a C-STORE operation using a referenced pixel data Transfer Syntax such as JPIP Referenced Pixel Data Transfer Syntax. This includes the duration of validity of the reference.]
[For implementations that store locally using multiple Transfer Syntaxes and if the SCU includes multiple Transfer Syntaxes in each Presentation Context it negotiates, the following can provide a useful summary for assessing compatibility with receiving systems. If this information is not useful for your product, replace the content of this Section with the text "N/A" and append "- N/A" to the end of the section title.]
Table N.5-9 describes supported transcodings between the locally stored encoding of SOP Instances and the negotiated Transfer Syntax. The following Values can be used:
[Table N.5-9 shows an example of how this transcoding could look, modify and add columns and rows as needed for Transfer Syntaxes supported by your product. If you need to provide further details on specific transcoding those can be added as notes below the table.]
Table N.5-9. Transcoding of Transfer Syntaxes
As a Service Class Provider of the Storage Service Class, the <Product> receives the C-STORE-RQ message from remote SCUs. See Section N.1.1 Content and Transfer in the Overview for the list of supported SOP Classes.
Table N.5-10 defines the conformance levels of <Product>.
The <Product> coerces the Attributes listed in Table N.5-11 upon receiving them from other systems.
The "SOP Class UID" column indicates whether the coercion is applicable to specific SOP Classes or to "ALL" SOP Classes.
The "Type of Change" column defines the coercion done to the Attributes, the following Values can be used:
The "Condition" column defines the condition under which coercion is performed. The following Values can be used:
ALWAYS: Data coercion is performed on each instance of the specified SOP Class that is received by the system.
EXTERNAL: Data coercion is performed on instances received from systems external to the institution.
CONFIGURATION: Data coercion is performed based on system configuration.
OTHER: Data coercion is performed for other conditions. Details are defined in the "Comments" column.
[Table N.5-11 defines some examples on which data coercion can be performed. Add/remove scenarios as they apply to your product implementation. In case you use OTHER as a condition, the "Comments" column must be used to define the condition in further detail. It is recommended to include Attributes that are coerced in the Modified Attributes Sequence (0400,0550) of the Original Attributes Sequence (0400,0561), which is documented in Section N.9.1.1.]
Table N.5-12 lists any limitations on displaying or processing instances, e.g., display or processing of the respective SOP Instances is prevented by an unsupported Value for an Attribute or the absence of that Attribute.
[When a Limitation is based on multiple Attributes (e.g., images cannot be displayed, if they are lossless compressed and encoded as Photometric Interpretation RGB), the Attributes are listed each in a row and the "Comments" and "Effect" cells are merged as shown in the example below. The "Comments" column is used to explain as necessary. Also use this mechanism when documenting restrictions based on Private Attributes, e.g., list the Private Creator attribute as well as the Private Attribute.]
The "Effect" column describes what happens if the limitation is encountered. The following Values are used:
[If there are no restrictions on display or processing requirements, replace the sentence above with No restriction to display or post processing apply.]
Table N.5-12. Display and Processing Limitations for Storage SCP
Table N.5-13 lists the actions performed upon receiving instances from a remote AE and the system behavior when certain conditions are encountered
[Fill in Table N.5-13 for details. The Table shows some examples which can be reused, modified, deleted, or extended based on your product implementation]
Table N.5-13. Behavior when storing Instances
Table N.5-14 describes how the SCP handles compression for stored instances.
The following Values are used in the "Behavior" column:
The Transfer Syntax is used to describe the compression mechanism applied.
Table N.5-14. Image Compression by Storage SCP
[Describe the mechanism by which additional SOP Classes are dynamically supported.]
As a Service Class User of the Storage Commitment SOP Class, the <Product> uses the N-ACTION-RQ message to request storage commitment from a remote SCP. In turn, it receives N-EVENT-REPORT-RQ messages from the SCP indicating success or failure of the request.
[Provide a list of Storage SOP Classes for which the product requests storage commitment. Also indicate whether this is configurable.]
[If Storage Commitment is provided for all supported SOP Classes, you can provide a reference to the list of supported Storage SOP Classes in Section N.1.1]
As a Service Class User of the Storage Commitment Push Model SOP Classes the product supports committing all Storage SOP Classes listed in Section N.1.1 Content and Transfer are supported.
[If Storage Commitment is provided for a subset of all supported Storage SOP Classes, provide a list of those, and delete the paragraph above.]
[Specify whether your product supports the Storage Media File Set ID and UID Attributes in the N-ACTION-Request. If this is supported, also list the Media Application profiles supported in this context.]
[Describe whether your product supports receiving the N-EVENT-REPORT request on the same Association as the N-ACTION.]
[Document the Behavior of <product> upon receiving an N-EVENT-REPORT with an Event Type ID of 1, e.g.
Upon receiving an N-EVENT-REPORT with an Event Type of 1 Instances will be removed from system after a configurable amount of time or if space is needed]
Table N.5-15 lists the behavior of <Product> for each possible Failure Reason (0008,1197) in the Failed SOP Sequence (0008,1198) upon receiving an N-EVENT-REPORT request from the SCP with an Event Type ID of 2 (Storage Commitment Request Complete - Failures Exist).
[Fill in the behavior of your product upon encountering the Status Code. Note that for each code, that is listed in the table, a behavior needs to be provided. If your system does not support specific codes, list "Code is ignored by the system".]
Table N.5-15. Failure Behavior for Storage Commitment SCU
[Describe your product behavior in case the N-EVENT-REPORT request is not received after a specific time, e.g., <Product> expects to receive the N-EVENT-REPORT request in a configurable time frame after the N-ACTION is sent. If the N-EVENT-REPORT is not received within this configurable timeframe it repeats the N-ACTION-REQUEST.]
[Describe the policies for deleting instances from your product, both upon successful storage commitment as well as in failure scenarios.]
As a Service Class Provider of the Storage Commitment SOP Class, the <Product> receives the N-ACTION-RQ message to request storage commitment from a remote SCU. In turn it initiates the N-EVENT_REPORT-RQ messages to the SCU indicating success or failure of the request.
[Describe whether your product supports sending the N-EVENT-REPORT request on the same Association as the N-ACTION.]
Table N.5-16 lists conditions upon which an error code is sent in the Failure Reason (0008,1197) Attribute in the Failed SOP Sequence (0008,1198) of the N-EVEN-REPORT request.
[Fill in the conditions under which your product is sending the listed Status Codes. Note that for each code listed in the table, a condition needs to be provided. If your system does not support specific codes, list "Code is not supported"]
Table N.5-16. Failure Conditions on Storage Commitment SCP
[Specify whether your product supports the Storage Media File Set ID and UID Attributes in the N-ACTION-Request. If this is supported, also list the Media Application profiles supported in this context.]
[Specify whether the Retrieve AE title Attribute is supported and if so, what policies exist for its usage.]
[Describe the policies and nature of commitment of the product, e.g., the duration of storage, retrieve capabilities, latency, capacity, and other pertinent information.]
[Describe how long the product typically needs to send the N-EVENT-REPORT-RQ after the N-ACTION-RQ is received.]
[The sections below define some of the most used Query Retrieve SOP Classes as examples, however, there are many more Query/Retrieve SOP Classes defined in DICOM PS 3.4. If your product supports any of these additional SOP Classes, add additional Sections for these SOP Classes for SCU and SCP using the structure as indicated for any of the SOP Classes below.]
As a Service Class User of the Study Root Q/R - Information Model - FIND SOP Class, the <Product> uses the C-FIND-RQ message and supports the Query Keys listed in Table N.5-17 for hierarchical queries.
In the "Matching Type" column the following Values can be used:
SINGLE_VALUE: SCU can request Single Value matching on this Attribute.
UID: SCU can request List of UID matching on this Attribute.
WILDCARD: SCU can request Wildcard matching on this Attribute.
SEQUENCE: SCU can request Sequence matching on this Attribute.
UNIVERSAL: SCU can request that the Attribute be a return Value (universal matching).
In the "Query Value Source" column the following Values can be used:
FIXED: The query Value cannot be modified by the user or by configuration.
GENERATED: The query Value is generated by the system (e.g., current date as the study date).
CONFIGURATION: The query Value is dependent on system configuration.
SCANNED: The query Value is read from a barcode scanner or similar device.
EMPTY: The query Value is sent with a zero-length value to indicate it is a return key only.
In the "Display on UI" column the following Values can be used:
[Modify Table N.5-17 to include all Attributes supported by your system (standard Attributes as well as private Attributes) and use the terms defined for matching type, query Value source and Display on UI above. If multiple codes are supported, list all of them.]
[If <product> supports Extended Negotiation for Relational Queries, describe supported matching Attributes.]
[Describe scenarios in which the SCU can issue C-FIND-CANCEL Requests, e.g.
The product issues C-FIND CANCEL requests in the following scenarios:* Configurable maximum of matches detected* Initiated by user]
[Also describe the behavior if the SCP ignores the cancellation request and continues sending responses.]
[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN), e.g.:
When configured for Japanese character set support, Person Name query attributes may contain ideographic (kanji) and/or phonetic (hiragana and katakana) and/or Romanized (romaji) representations.
When configured for Chinese character set support, Person Name query attributes may contain ideographic (hanzi) and/or phonetic (pinyin) representations are supported. For Patient’s Name (0010,0010), the representation which is displayed by default in the worklist is configurable.
When configured for Korean character set support, Person Name query attributes may contain ideographic (hanja) and/or phonetic (hangul) and/or Romanized representations.
If the product receives from the SCP a C-FIND response containing unsupported values in Specific Character Set (0008,0005), characters in that character set will be treated as unknown characters as described in Section 6.1.2.3 in PS3.5 .
If a Person Name attribute contains multiple representations, the GUI will display one representation based on a configurable order of preference.]
[If this SOP Class is supported, fill in the section as indicated in Section N.5.2.7.1.]
[Describe if List of UID matching may be used to retrieve multiple entities at STUDY, SERIES, or IMAGES levels.]
[Also specify the conditions under which a C-MOVE CANCEL may be sent.]
[Indicate whether your product supports sending matching instances to a different AE Title.]
[Indicate your product behavior in case no C-STORE Request is received after a specific time, e.g., <Product> expects to receive the C-STORE Request in a configurable time frame after the C-MOVE Request is sent. If no C-STORE Requests are received within this configurable timeframe, it repeats the C-MOVE-Request.]
[If this SOP Class is supported, fill in the section as indicated in Section N.5.2.7.3.]
As a Service Class Provider of the Study Root Q/R - Information Model - FIND SOP Class, the <Product> uses the C-FIND-RSP to communicate matches back to the SCU. It supports the Matching Keys listed in Table N.5-18 for hierarchical queries.
In the "Matching Type" column, the following Values can be used:
SINGLE_VALUE: SCP can perform single Value matching on this Attribute.
UID: SCP can perform List of UID matching on this Attribute.
WILDCARD: SCP can perform Wildcard matching on this Attribute.
SEQUENCE: SCP can perform sequence matching on this Attribute.
UNIVERSAL: SCP can provide the Attribute in the C-FIND response (universal matching).
[Table N.5-18 contains a set of Attributes (standard Attributes as well as private Attributes) that could be supported by a product. Add and remove Attributes in order to match your product implementation using the matching type as defined above. If multiple codes are supported, list all of them. Use the "Comments" column if clarification is needed.]
[If <product> supports Extended Negotiation for Relational Queries, describe supported matching Attributes.]
[Document your product behavior in case you are encountering non supported private Attributes.]
[Describe the behavior of the product if it receives a C-FIND-CANCEL Request.]
[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN), e.g.:
If the product receives from the SCU a Request Identifier containing unsupported values in the Specific Character Set (0008,0005), then no matching is performed and an error will be returned indicating the SCP is unable to process the request.]
[Document your product's query capabilities and behavior for handling implementation-dependent matching of VRs, such as for DA, DT, TM, IS and DS.]
[If your product supports Extended Negotiation for fuzzy semantic matching of person names describe how matching is performed, e.g., whether your matching is insensitive to case, position, accent, or character encoding, or whether you support phonetic matching.]
[If this SOP Class is supported, fill in the section as indicated in Section N.5.2.7.5.]
As the SCP of the Study Root Q/R - Information Model - MOVE, the <Product> receives the C-MOVE-RQ and in turn uses the C-STORE-RQ sub operation to send matching SOP Instances to the Move Destination AE included in the C-MOVE-RQ.
[Provide a list of Storage SOP Classes supported or reference Storage Table in Overview e.g.]
As the SCP of the Storage Service Class, all Storage SOP Classes listed in Section N.1.1 are supported.
[Describe the relationship between the incoming C-MOVE Request and the C-STORE Sub-operation, e.g., is each instance sent on one Association or is the same Association used for all instances, is this behavior configurable.]
[Describe your product behavior if a C-MOVE-CANCEL Request is received.]
[If this SOP Class is supported, fill in the section as indicated in Section N.5.2.7.7.]
The Basic Grayscale Print Management Meta SOP Class is composed of the mandatory SOP Classes listed in Table N.5-19.
Table N.5-20 lists the supported DIMSE Services for the Basic Film Session SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported ones.]
Table N.5-21 lists the supported N-CREATE and N-SET Attributes for Basic Film Session:
[List the supported Attributes and their possible values / ranges. List the default Value when relevant. All tags are optional for the SCU in the Basic Film session. See example below.]
Table N.5-22 lists the supported DIMSE Services for the Basic Film Box SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported ones.]
Table N.5-23 lists the supported N-CREATE and N-SET Attributes for Basic Film Box:
[List the supported Attributes and their possible Values. Provide the default Value when relevant. See example below.]
Table N.5-23. Supported N-CREATE and N-SET Attributes for the Basic Film Box SOP Class - SCU
Table N.5-24 lists the supported DIMSE Service for the Basic Grayscale Image Box SOP Class:
Table N.5-25 lists the supported N-SET Attributes for Basic Grayscale Image Box:
[List the supported Attributes and their possible Values. Provide the default Value when relevant. See example below.]
Table N.5-26 lists the supported DIMSE Services for the Printer SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported ones.]
An N-EVENT-REPORT request can be received by the SCU at any time during an Association.
Table N.5-27 summarizes the behavior of the SCU when receiving Event Types within the N-EVENT-REPORT.
[Remove the following text and table if N-GET is not supported.]
Table N.5-28 lists the supported N-GET Attributes for Printer SOP Class:
[List the supported Attributes and the behavior of the SCU when receiving Printer Status / Printer status info. Remove the non-supported Attributes from the table.]
The Basic Color Print Management Meta SOP Class is composed of the mandatory SOP Classes listed in Table N.5-29:
[If your system also supports the Basic Grayscale Print Management Meta SOP Class and the Film Session parameters are identical for color, see Section N.5.2.8.1.1 Basic Film Session SOP Class for Basic Grayscale Print Management Meta SOP Class. Otherwise, copy the Film Session table here and fill in the proper Values.]
[If your system also supports the Basic Grayscale Print Management Meta SOP Class and the Film Box parameters are identical for color, see Section N.5.2.8.1.2 Basic Film Box SOP Class for Basic Grayscale Print Management Meta SOP Class. Otherwise copy the Film Box table here and fill in the proper Values.]
Table N.5-30 lists the supported DIMSE Service for the Basic Color Image Box SOP Class:
Table N.5-31 lists the supported N-SET Attributes for Basic Color Image Box:
[List the supported Attributes and their possible Values. Provide the default Value when relevant. See example below.]
[If your system also supports the Basic Grayscale Print Management Meta SOP Class, see 'Printer SOP Class' for 'Basic Grayscale Print Management Meta SOP Class' in Section N.5.2.8.1.4. Otherwise copy the Printer SOP Class table here and fill in the proper Values.]
Table N.5-32 lists the supported DIMSE Service for the Basic Annotation Box SOP Class:
Table N.5-33 lists the supported N-SET Attributes for the Basic Annotation Box SOP Class:
[List the supported Attributes and their possible Values. Provide the default Value when relevant. See example below.]
Table N.5-34 lists the supported DIMSE Services for the Print Job SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported one.]
An N-EVENT-REPORT request can be received by the SCU at any time during an Association if the Print Job SOP Class has been negotiated by the SCU.
Table N.5-35 summarizes the behavior of the SCU when receiving Event Types within the N-EVENT-REPORT.
[Remove the following text and table if N-GET is not supported.]
Table N.5-36 lists the supported N-GET Attributes for Print Job SOP Class:
[List the supported Attributes and the behavior of the SCU when receiving Execution Status / Execution Status Info. Remove the non-supported Attributes from the table.]
Table N.5-37 lists the supported DIMSE Services for the Presentation LUT SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported one.]
Table N.5-38 lists the supported N-CREATE Attributes for Presentation LUT:
[List the supported Attributes. Either Presentation LUT Sequence or Presentation LUT Shape must be present (not both).]
Table N.5-39 lists the supported DIMSE for the Printer Configuration Retrieval SOP Class:
The Basic Grayscale Print Management Meta SOP Class is composed of the mandatory SOP Classes listed in Table N.5-40:
Table N.5-41 lists the supported DIMSE Services for the Basic Film Session SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported one.]
Table N.5-42 lists the supported N-CREATE and N-SET Attributes for Basic Film Session:
[List the supported Attributes and their possible values/ranges. Indicate the default Value when relevant. See example below.]
[If the SCP supports N-ACTION for the Film Session SOP Class, then the SCP must specify the maximum number of collated films.]
Table N.5-43 lists the supported DIMSE Services for the Basic Film Box SOP Class:
[List the supported DIMSE Service Elements. Remove the non-supported one.]
Table N.5-44 lists the supported N-CREATE and N-SET Attributes for Basic Film Box:
[List the supported Attributes and their possible Values. Indicate the default Value when relevant. See example below.]
Table N.5-44. Supported N-CREATE and N-SET Attributes for Basic Film Box - SCP
[Describe each supported custom Image Display Format (2010,0010) and provide details such as position and dimensions of each composing Image Box, including the numbering scheme of the image positions.]
[Describe each supported Annotation Display Format ID (2010,0030) (e.g., position and dimensions of annotation box, font, number of characters).]
[Describe supported configuration information (e.g., identification, content).]
Table N.5-45 lists the supported DIMSE Service for the Basic Grayscale Image Box SOP Class:
Table N.5-46 lists the supported N-SET Attributes for Basic Grayscale Image Box:
[List the supported Attributes and their possible Values. Indicate the default Value when relevant. See example below.]
[If cropping or decimating of images is supported, describe the algorithm for removing rows and columns from the image.]
Table N.5-47 lists the supported DIMSE Services for the Printer SOP Class:
Table N.5-48 lists the Printer SOP Class N-EVENT-REPORT Behavior:
Table N.5-48. Printer SOP Class N-EVENT-REPORT Behavior
Table N.5-49 lists the supported N-GET Attributes for Printer SOP Class:
[List the supported Attributes. Remove the non-supported Attributes from the Table]
Table N.5-49. Supported N-GET Attributes for the Printer SOP Class - SCP
The Basic Color Print Management Meta SOP Class is composed of the mandatory SOP Classes listed in Table N.5-50:
[If your system also supports the Basic Grayscale Print Management Meta SOP Class and the Film Session parameters are identical for color, see 'Basic Film Session SOP Class' for 'Basic Grayscale Print Management Meta SOP Class' in Section N.5.2.8.7.1. Otherwise copy the Film session table here and fill in the proper Values.]
[If your system also supports the Basic Grayscale Print Management Meta SOP Class and the Film Box parameters are identical for color, see 'Basic Film Box SOP Class' for 'Basic Grayscale Print Management Meta SOP Class' in Section N.5.2.8.7.2. Otherwise copy the Film Box Table here and fill in the proper Values.]
Table N.5-51 lists the supported DIMSE Service for the Basic Color Image Box SOP Class:
Table N.5-52 lists the supported N-SET Attributes for Basic Color Image Box:
[List the supported Attributes and their possible Values. Indicate the default Value when relevant. See example below.]
[In case your printer is a grayscale printer that supports printing of color images (e.g., it supports the Basic Color Print Management Meta SOP Class), describe the behavior when printing color images.]
[If your system also supports the Basic Grayscale Print Management Meta SOP Class, see 'Printer SOP Class' for 'Basic Grayscale Print Management Meta SOP Class' in Section N.5.2.8.7.4. Otherwise copy the Printer SOP Class Table here and fill in the proper Values.]
Table N.5-53 lists the supported DIMSE Service for the Basic Annotation Box SOP Class:
Table N.5-54 lists the supported N-SET Attributes for Basic Annotation Box SOP Class:
[List the supported Attributes and their possible Values. Indicate the default Value when relevant. See example below.]
Table N.5-55 lists the supported DIMSE Services for the Print Job SOP Class:
An N-EVENT-REPORT request can be sent by the SCP at any time during an Association if the print Job SOP Class has been negotiated by the SCU.
Table N.5-56 lists the supported Event Types and Attributes within the N-EVENT-REPORT.
Table N.5-56. Print Job SOP Class N-EVENT-REPORT- SCP
[Remove the complete table if N-GET is not supported.]
Table N.5-57 lists the supported N-GET Attributes for Print Job SOP Class:
[List the supported Attributes and the supported Values when relevant. Remove the non-supported Attributes from the table.]
Table N.5-57. Supported N-GET Attributes for the Print Job SOP Class - SCP
Table N.5-58 lists the supported DIMSE Services for the Presentation LUT SOP Class:
Table N.5-59 lists the supported N-CREATE Attributes for Presentation LUT:
[List the supported Attributes in Table N.5-59.]
Table N.5-60 lists the supported DIMSE Services for the Printer Configuration Retrieval SOP Class:
This section provides details regarding the URI Web Service. For an overview of the supported transactions see Table N.1-8 URI Service.
The supported DICOM Storage SOP Classes / Transfer Syntaxes are listed in Section N.1.1 of this document.
[Provide requirements for display and processing of instances received via Web Services. This could either be done by referencing Section N.5.2.5.2 if the same requirements apply, or by copying the tables from Section N.5.2.5.2 and filling them appropriately, if the requirements for Web Services differ.]
Table N.5-61 lists the supported rendered Media types depending on the Media Type category.
[Indicate which category / Media types are supported by your system by marking the cells with Y or N. Remove rows for Media Types neither supported as user agent nor as Origin Server].
[Provide requirements for display and processing of instances retrieved via URI Web Service. This could either be done by referencing Section N.5.2.5.2 (as indicated below), if the same requirements apply, or by copying the tables from Section N.5.2.5.2 and filling them appropriately if requirements for retrieved instances differ.]
In order to display or process DICOM instances retrieved via URI Web Service, see Section N.5.2.5.2.
The URI Web Service user agent supports the Query Parameters listed in Table N.5-62.
[List the supported parameters and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-62. Query Parameters for Retrieve DICOM Instance URI Web Service - User Agent
|
[Must be compatible with the acceptable Media Types in the HTTP Header] See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer Syntaxes. Look for "Y" in the "UA" column |
||
The URI Web Service User Agent supports the Header Fields listed in Table N.5-63:
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-63. Header Fields for Retrieve DICOM Instance URI Web Service - User Agent
|
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer Syntaxes. Look for "Y" in the "UA" column |
||
The URI Web Service origin server receives GET requests for studies, series and instances containing query parameters and headers fields. Supported Values are listed in the query parameters and header fields tables (Table N.5-64 and Table N.5-65).
The URI is composed by a Base URI: see Section N.6.3.1 for the Base URI of the Origin Server.
The URI Web Service origin server supports the Query Parameters listed in Table N.5-64.
[List the supported parameters and their Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-64. Query Parameters for Retrieve DICOM Instance URI Web Service - Origin Server
|
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer Syntaxes. Look for "Y" in the "OS" column |
||
The URI Web Service origin server supports the Header Fields listed in Table N.5-65.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-65. Header Fields for Retrieve DICOM Instance URI Web Service - Origin Server
|
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer Syntaxes. Look for "Y" in the "OS" column |
||
[Provide requirements for display and processing of instances retrieved via URI Web Service. This could either be done by referencing section 5.2.5.2 (as indicated below), if the same requirements apply, or by copying the tables from Section 5.2.5.2 and filling them appropriately if requirements for retrieved instances differ.]
To display or process DICOM instances retrieved via URI Web Service, see Section N.5.2.5.2.
The URI Web Service user agent supports the Query Parameters listed in Table N.5-66.
[List the supported parameters and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-66. Query Parameters for Retrieve Rendered Instance URI Web Service - User Agent
|
See Section N.5.3.1.1.2 for details |
||
|
[if presentationUID specified then presentationSeriesUID must be present.] |
The URI Web Service user agent supports Header Fields listed in Table N.5-67.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-67. Header Fields for Retrieve Rendered Instance URI Web Service - User Agent
|
See Section N.5.3.1.1.2 for details |
||
The URI Web Service origin server receives GET requests for studies, series and instances containing query parameters and headers fields. Supported Values are listed in the query parameters and header fields tables (Table N.5-68 and Table N.5-69).
The URI is composed by a Base URI: see Section N.6.3.1 for the Base URI of the origin server.
The URI Web Service origin server supports Query Parameters listed in Table N.5-68.
[List the supported parameters and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-68. Query Parameters for Retrieve Rendered Instance URI Web Service - Origin Server
|
See details in Section N.5.3.1.1.2 |
||
|
[if presentationUID specified then presentationSeriesUID must be present.] |
The URI Web Service origin server supports Header Fields listed in Table N.5-69.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-69. Header Fields for Retrieve Rendered Instance URI Web Service - Origin Server
|
See details in Section N.5.3.1.1.2 Rendered Media Types |
This section provides details regarding the Studies Web Service. For an overview of supported transactions and resources see Table N.1-9 Study Service.
The supported DICOM Storage SOP Classes / Transfer Syntaxes are listed in Section N.1.1 of this document.
[Provide requirements for display and processing of instances received via Web Services. This could either be done by referencing Section N.5.2.5.2 if the same requirements apply, or by copying the tables from Section N.5.2.5.2 and filling them appropriately, if requirements for Web Services differ.]
[Indicate in the Table the combination media type / Transfer Syntaxes supported by your user agent and / or origin server for each category. Remove the unsupported Media Types.X represents the default Transfer Syntaxes to be supported for each category.]
Uncompressed Bulkdata is transferred using Explicit VR Little Endian Transfer Syntax.
Table N.5-70 lists the supported Media Types and Transfer Syntax UIDs for Compressed Bulkdata.
Table N.5-70. DICOM Compressed Bulkdata Media Types
Table N.5-71 lists the supported Rendered Media types for each Media Type category.
[Indicate which category / Media types are supported by your system by marking the cells with Y or N. Remove rows for Media Types neither supported as user agent nor as origin server.
In the Transformation column specify to which Transfer Syntax UID the origin server transforms the received image. N/A indicates that the media type does not require transformation since there is an existing DICOM Transfer Syntax for it.]
The Studies Web Service Retrieve Transaction is also known as WADO-RS.
The Retrieve Transaction user agent can request resources listed in Table N.5-72:
[List the supported resources for your Retrieve Transaction user agent. Remove the non-supported resources rows. Fill in specific details on your implementation in the in the "Comments" column, when necessary.]
Table N.5-72. Resources Retrieve Transaction - User Agent
|
DICOM Instance Resources - See Resources path in Table 10.4.1-1 in PS3.18 |
|
|
DICOM Metadata Resources - See Resources path in Table 10.4.1-2 in PS3.18 |
|
|
DICOM Bulkdata Resources - See Resources path in Table 10.4.1.5-1 in PS3.18 |
|
|
DICOM Pixel Data Resources - See Resources path in Table 10.4.1.6-1 in PS3.18 |
|
|
Rendered Resources - See Resources path in Table 10.4.1-3 in PS3.18 |
|
|
Rendered MPR Volume Resources - See Resources path in Table 10.4.1.7-1 in PS3.18 |
|
|
Rendered 3D Volume Resources - See Resources path in Table 10.4.1.8-1 in PS3.18 |
|
|
Thumbnail Resources - See Resources path in Table 10.4.1-4 in PS3.18 |
|
[If rendering of thumbnails is supported, provide a high-level description of the method used for rendering thumbnails for the study, series, or instance.
For example, the description could indicate whether a representative instance is chosen from a series, and how that instance is selected, or that per-modality fixed content is used.]
The Retrieve Transaction user agent supports the Query Parameters listed in Table N.5-73.
[Include a row in the table for each parameter your user agent is able to send, including parameters always sent and parameters optionally sent. Remove the rows for parameters your user agent is not able to send. See Section 8.3.5 in PS3.18 for the list of Rendering Query Parameters.
For each row, indicate in the Supported Values column specific Values your user agent may send and/or a description of how the Value is populated. The "Comments" column may be used to explain details of your implementation that may be useful to integrators, such as:
Table N.5-73. Query Parameters for Retrieve Transaction - User Agent
|
Attribute Values to address the search (matching key). See the supported DICOM Attribute in the Table N.5-84 |
||
|
Attribute Values to address the search (matching key). See the supported DICOM Attribute in the Table N.5-84 |
||
The Retrieve Transaction user agent supports Header Fields listed in Table N.5-74.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary. See Section 10.4.4 in PS3.18 for the list of resources and their corresponding Media Types.]
Table N.5-74. Header Fields for Retrieve Transaction - User Agent
|
multipart/related; type="application/dicom"; transfer-syntax={uid} |
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer Syntaxes. Look for "Y" in the "UA" column. |
|
|
<<multipart/related; type="application/octet-stream">> |
See details in Section N.5.3.2.1.2. |
|
|
See details in Section N.5.3.2.1.3. |
||
|
See details in Section N.5.3.2.1.3. |
||
|
See details in Section N.5.3.2.1.3. |
||
|
See details in Section N.5.3.2.1.3. |
||
The Retrieve Transaction origin server receives GET requests to retrieve specific studies, series or instances.
The user agent specifies the Target Resource as part of the URI and the acceptable response Content-Type in the HTTP Header (i.e., dicom, dicom+xml, dicom+json, octet-stream, compressed pixel data).
The URI is composed by a Base URI: see Section N.6.3.2.1 for the Base URI of the origin server
The Retrieve Transaction origin server supports resources listed in Table N.5-75.
[List the supported resources for your Retrieve Transaction origin server. Remove the non-supported resources rows.Fill in information on your implementation in the Comments column when necessary.]
Table N.5-75. Resources Retrieve Transaction - Origin Server
|
DICOM Instance Resources - See Resources path in Table 10.4.1-1 in PS3.18 |
|
|
DICOM Metadata Resources - See Resources path in Table 10.4.1-2 in PS3.18 |
|
|
DICOM Bulkdata Resources - See Resources path in Table 10.4.1.5-1 in PS3.18 |
|
|
DICOM Pixel Data Resources - See Resources path in Table 10.4.1.6-1 in PS3.18 |
|
|
Rendered Resources - See Resources path in Table 10.4.1-3 in PS3.18 |
|
|
Rendered MPR Volume Resources - See Resources path in Table 10.4.1.7-1 in PS3.18 |
|
|
Rendered MPR Volume Resources - See Resources path in Table 10.4.1.7-1 in PS3.18 |
|
|
Thumbnail Resources - See Resources path in Table 10.4.1-4 in PS3.18 |
|
Table N.5-76 lists Query parameters supported for the Retrieve Transaction as an origin server.
[List the supported parameters and their supported Values. Fill in information on your implementation in the "Comments" column when necessary. See Section 8.3.5 in PS3.18 for the list of Rendering Query Parameters.]
Table N.5-76. Query Parameters for Retrieve Transaction - Origin Server
|
[Supported Values are the same as for the Accept Header Field.] |
||
|
Attribute Values to address the search (matching key). See the supported DICOM Attribute in the Table N.5-84 |
||
|
Attribute Values to address the search (matching key). See the supported DICOM Attribute in the Table N.5-84 |
||
The Retrieve Transaction origin server supports Header Fields listed in Table N.5-77.
[List the supported Header Field and their supported Values. Fill in information on your implementation in the "Comments" column when necessary. See Section 10.4.4 in PS3.18 for the list of resources and their corresponding Media Types.]
Table N.5-77. Header Fields for Retrieve Transaction - Origin Server
|
multipart/related; type="application/dicom"; transfer-syntax={uid} |
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer Syntaxes. Look for "Y" in the "OS" column. |
|
|
<<multipart/related; type="application/octet-stream">> |
See details in Section N.5.3.2.1.2. |
|
|
See details in Section N.5.3.2.1.3. |
||
|
See details in Section N.5.3.2.1.3. |
||
|
See details in Section N.5.3.2.1.3. |
||
|
See details in Section N.5.3.2.1.3. |
||
|
Content-Type returned by the origin server in the response. It contains the media type of the Payload. See Accept for supported Values |
||
For details regarding the IODs created by the system, see Section N.9.
The Store Transaction user agent can request resources listed in Table N.5-78.
[List the supported resources for your Store Transaction user agent. Remove the non-supported resources rows.Fill in information on your implementation in the Comments column when necessary.]
Table N.5-78. Resources Store Transaction - User Agent
|
See resource path in Table 10.5.1-1 in PS3.18 |
|
The Store Transaction user agent supports Header Fields listed in Table N.5-79.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-79. Header Fields for Store Transaction - User Agent
|
multipart/related; type="application/dicom"; transfer-syntax={uid} |
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer syntaxes (look for "Y" in the "UA" column) |
|
|
multipart/related; type="application/dicom+xml"; boundary={messageBoundary} multipart/related; type="application/dicom+json"; boundary={messageBoundary} |
||
|
multipart/related; type="application/octet-stream" |
See details in Section N.5.3.2.1.2. |
|
The Store Transaction origin server receives POST requests to store or append to an existing resource on the server.
The user agent specifies the Target Resource as part of the URI and encapsulates the data in a multipart request body with a proper Content-Type (i.e., BINARY, XML or JSON).
The URI is composed by a Base URI: see Base URI for the origin server in Section N.6.3.2.2.
The Store Transaction origin server can request resources listed in Table N.5-80.
[Fill in information on your implementation in the Comments column when necessary.]
Table N.5-80. Resources Store Transaction - Origin Server
|
See resource path in Table 10.5.1-1 in PS3.18 |
|
The Store Transaction origin server supports Header Fields listed in Table N.5-81.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-81. Header Fields for Store Transaction - Origin Server
|
multipart/related; type="application/dicom"; boundary={messageBoundary} multipart/related; type="application/dicom+xml"; boundary={messageBoundary} multipart/related; type="application/dicom+json"; boundary={messageBoundary} |
See in the Overview section Table N.1-1 the supported DICOM SOP Classes / Transfer syntaxes (look for "Y" in the "OS" column) |
|
|
multipart/related; type="application/dicom+xml"; boundary={messageBoundary} multipart/related; type="application/dicom+json"; boundary={messageBoundary} |
||
|
multipart/related; type="application/octet-stream" |
See details in Section N.5.3.2.1.2. |
|
The Search Transaction user agent can request resources listed in Table N.5-82.
[List the supported resources for your Search Transaction user agent. Remove the non-supported resources rows. Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-82. Resources Search Transaction - User Agent
|
See resource path in Table 10.6.1-1 in PS3.18 |
|
The Search Transaction user agent supports query parameters listed in Table N.5-83.
[Indicate the supported parameters and their supported Values. For detail on the implementation possibilities see Table 8.3.4-1 in PS3.18. Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-83. Query Parameters for Search Transaction - User Agent
|
Attribute Values to address the search (matching key). See the supported DICOM Attribute in the Table N.5-84 |
||
|
Attributes to be included in the response (return key). See the supported DICOM Attributes in the Table N.5-84 |
||
|
[Number of results the server skips before the first returned result.] |
[Indicate which DICOM query Attributes are supported and if they are supported as Matching and/or Return (include) key. Add or remove Attributes according to your implementation. If the tables are the same as used in DIMSE Services, you can enter a reference to Table N.5-17 and remove the text and table below. Otherwise provide the following text and Table N.5-84.]
Table N.5-84 lists the DICOM query Attributes supported by the Search Transaction user agent.
Table N.5-84. Supported Query Attributes User Agent
The Search Transaction user agent supports Header Fields listed in Table N.5-85.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-85. Header Fields for Search Transaction - User Agent
|
See Section N.5.7 for supported Values |
The Search Transaction origin server receives GET requests to search for studies, series or instances.
[Specify here if this is a native or a DIMSE proxy implementation.]
The user agent specifies the Target Resource as part of the URI and the acceptable response Content-Type in the HTTP Header (i.e., dicom+xml or dicom+json).
The URI is composed by a Base URI: see Base URI for the origin server in Section A.6.3.2.3.
The Search Transaction origin server supports resources listed in Table N.5-86.
[Fill in information on your implementation in the Comments column when necessary.]
Table N.5-86. Resources Search Transaction - Origin Server
|
See resource path in Table 10.6.1-1 in PS3.18 |
||
The Search Transaction origin server supports query parameters listed in Table N.5-87.
[List the supported parameters and their supported Values. For detail on the implementation possibilities see Table 8.3.4-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-87. Query Parameters for Search Transaction - Origin Server
|
Attribute Values to address the search (matching key). See the supported DICOM Attributes provided in the response in the Table N.5-89 |
||
|
Attributes to be included in the response (return key). See the supported DICOM Attributes provided in the response in the Table N.5-89 |
||
|
Number of results the server skips before the first returned result |
The Search Transaction origin server supports Header Fields listed in Table N.5-88.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-88. Header Fields for Search Transaction - Origin Server
[Indicate which DICOM query Attributes are supported / returned in the response and if they are supported as Matching and/or Return (include) key. If the tables are the same as used in DIMSE Services, you can enter a reference to Table N.5-18 and remove the text and table below. Otherwise provide the following text and Table N.5-89, and add or remove Attributes according to your implementation. In the table below, Attributes / matching /return keys in regular font style are mandatory to be supported.]
Table N.5-89 lists the DICOM query / returned Attributes supported by the Search Transaction origin server.
Table N.5-89. Query / Return Key Search Transaction - Origin Server
This section provides details regarding the Worklist Web Service. For an overview of supported transactions and resources see Table N.1-10 Worklist Service.
The Worklist Web Service user agent can request resources listed in Table N.5-90 for the Create Workitem Transaction.
[Indicate the supported resources. Remove the non-supported resources rows.Fill in information on your implementation in the Comments column when necessary.]
Table N.5-90. Resources for the Worklist Web Service Create Transaction - User Agent
|
See resource path in Section 11.4.1.1 in PS3.18 |
|
Table N.5-91 lists the Query parameters supported by Worklist Web Service user agent for the Create Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-92 lists the Header fields supported by the Worklist Web Service user agent for the Create Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.4.1-3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-92. Header Fields for Worklist Web Service Create Workitem Worklist Web Service - User Agent
The Worklist Web Service origin server supports resources listed in Table N.5-93 for the Create Transaction:
[Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-93. Resources for the Worklist Web ServiceCreate Transaction - Origin Server
|
See resource path in Section 11.4.1.1 in PS3.18 |
|
Table N.5-94 lists the Query parameters supported by Worklist Web Service origin server for the Create Transaction.
[Indicate the supported parameters and their supported Values. See possible parameters / Values in Table 11.4.1-3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-95 lists the Header fields supported by the Worklist Web Service origin server for the Create Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.4.1-3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Retrieve Workitem Transaction user agent can request resources listed in Table N.5-96.
[Fill in information on your implementation in the Comments column when necessary.]
Table N.5-96. Resources for Worklist Web Service Retrieve Transaction - User Agent
|
See resource path in Section 11.5.1 in PS3.18 |
|
Table N.5-97 lists the Query parameters supported by Worklist Web Service user agent for the Retrieve Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in the Table 11.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-98 lists the Header fields supported by the Worklist Web Service user agent for the Retrieve Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.5.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Retrieve Workitem Transaction origin server can request Resources listed in Table N.5-99.
[Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-99. Resources for Worklist Web Service Retrieve Transaction- Origin Server
|
See resource path in Section 11.5.1 in PS3.18 |
|
Table N.5-100 lists the Query parameters supported by Worklist Web Service origin server for the Retrieve Transaction.
[Indicate the supported parameters and their supported Values. See possible parameters / Values in PS 3.18 Table 11.1.2-1. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-101 lists the Header fields supported by the Worklist Web Service origin server for the Retrieve Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.5.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Update Workitem Transaction user agent can request resources listed in Table N.5-102.
[Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-102. Resources for Worklist Web Service Update Transaction - User Agent
|
See resource path in Section 11.6.1 in PS3.18. |
|
Table N.5-103 lists the Query parameters supported by Worklist Web Service user agent for the Update Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Section 11.6.1.2 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-104 lists the Header fields supported by the Worklist Web Service user agent for the Update Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 11.6.1.3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Update Workitem Transaction origin server can request resources listed in Table N.5-105.
[Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-105. Resources for t Worklist Web Service Update Transaction - Origin Server
|
See resource path in Section 11.6.1 in PS3.18 |
|
Table N.5-106 lists the Query parameters supported by Worklist Web Service origin server for the Update Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Section 11.6.1.2 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-107 lists the Header fields supported by the Worklist Web Service user agent for the Update Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 11.6.1.3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Change State Transaction user agent can request resources listed in Table N.5-108.
Table N.5-108. Resources for Worklist Web Service Change State - User Agent
|
See resource path in Table 11.1.1-1 in PS3.18. |
|
Table N.5-109 lists the Query parameters supported by Worklist Web Service user agent for the Change State Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-110 lists the Header fields supported by the Worklist Web Service user agent for the Change State Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.7.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Worklist Web Service origin server supports resources listed in Table N.5-111 for the Change State Transaction
Table N.5-111. Resources for Worklist Web Service Change State - Origin Server
|
See resource path in Table 11.1.1-1 in PS3.18. |
|
Table N.5-112 lists the Query parameters supported by Worklist Web Service origin server for the Change State Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-113 lists the Header fields supported by the Worklist Web Service origin server for the Change State Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.7.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
[If your system does not support the Worklist Web Service Request Cancellation Transaction as user agent, you can indicate that this section is not applicable and remove the Table and subsections below.]
The Request Cancellation Transaction user agent can request resources listed in Table N.5-114.
Table N.5-114. Resources for the Worklist Web Service Request Cancellation Transaction - User Agent
|
See resource path in Section 11.8.1 in PS3.18. |
|
Table N.5-115 lists the Query parameters supported by Worklist Web Service user agent for the Request Cancellation Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-116 lists the Header fields supported by the Worklist Web Service user agent for the Request Cancellation Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.8.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Worklist Web Service origin server supports resources listed in Table N.5-117 for the Request Cancellation Transaction.
Table N.5-117. Resources for the Worklist Web Service Request Cancellation - Origin Server
|
See resource path in Section 11.8.1 in PS3.18. |
|
Table N.5-118 lists the Query parameters supported by Worklist Web Service origin server for the Request Cancellation Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-118. Query Parameters for Worklist Web Service Request Cancellation Transaction - Origin Server
Table N.5-119 lists the Header fields supported by the Worklist Web Service origin server for the Request Cancellation Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.8.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-119. Header Fields for Worklist Web Service Request Cancellation Transaction - Origin Server
The Search Transaction user agent can request resources listed in Table N.5-120.
Table N.5-120. Resources for Worklist Web Service Search Transaction - User Agent
|
See resource path in Section 11.9.1 in PS3.18. |
|
Table N.5-121 lists the Query parameters supported by Worklist Web Service user agent for the Search Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 8.3.4-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-122 lists the Header fields supported by the Worklist Web Service user agent for the Search Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.9.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Worklist Web Service origin server supports resources listed in Table N.5-123 for the Search Transaction.
Table N.5-123. Resources for Worklist Web Service Search Transaction - Origin Server
|
See resource path in Section 11.9.1 in PS3.18. |
|
|
/workitems?{&match*}{&includefield}{&fuzzymatching}{&offset}{&limit} |
Table N.5-124 lists the Query parameters supported by Worklist Web Service origin server for the Search Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 8.3.4-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-125 lists the Header fields supported by the Worklist Web Service origin server for the Search Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 11.9.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
[If your system does not support the Worklist Web Service Subscribe Transaction, you can indicate that this section is not applicable and remove the subsections below.]
The Subscribe Transaction user agent can request resources listed in Table N.5-126.
[List the supported resources. Remove the non-supported resources rows. Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-126. Resources for Worklist Web Service Subscribe Transaction - User Agent
|
See resource path in Table 11.10.1-1 in PS3.18. |
|
Table N.5-127 lists the Query parameters supported by Worklist Web Service user agent for the Subscribe Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.10.1-2 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-128 lists the Header fields supported by the Worklist Web Service user agent for the Subscribe Transaction:
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 8.4.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Worklist Web Service origin server supports resources listed in Table N.5-129 for the Subscribe Transaction.
[List the supported resources. Remove the non-supported resources rows. Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-129. Resources for Worklist Web Service Subscribe Transaction - Origin Server
|
See resource path in Table 11.10.1-1 in PS3.18. |
|
Table N.5-130 lists the Query parameters supported by Worklist Web Service origin server for the Subscribe Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 11.10.1-2 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-131 lists the Header fields supported by the Worklist Web Service origin server for the Subscribe Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in the DICOM Table 8.4.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Unsubscribe Transaction user agent can request resources listed in Table N.5-132.
[List the supported resources. Remove the non-supported resources rows. Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-132. Resources for Worklist Web Service Unsubscribe Transaction - User Agent
|
See resource path in Table 11.11.1-1 in PS3.18. |
|
Table N.5-133 lists the Header fields supported by the Worklist Web Service user agent for the Unsubscribe Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 8.4.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Worklist Web Service origin server supports resources listed in Table N.5-134 for the Unsubscribe Transaction.
Table N.5-134. Resources for Worklist Web Service Unsubscribe Transaction - Origin Server
|
See resource path in Table 11.11.1-1 in PS3.18. |
|
|
/workitems/1.2.840.10008.5.1.4.34.5/subscribers/{aetitle}{/suspend} |
|
|
/workitems/1.2.840.10008.5.1.4.34.5.1/subscribers/{aetitle}{/suspend} |
Table N.5-135 lists the Header fields supported by the Worklist Web Service origin server for the Unsubscribe Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 8.4.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The Suspend Global Subscription Transaction user agent can request resources listed in Table N.5-136.
[List the supported resources. Remove the non-supported resources rows. Fill in specific details of your implementation if available in the "Comments" column.]
Table N.5-136. Resources for Worklist Web Service Suspend Global Subscription Transaction - User Agent
|
See resource path in Table 11.12.1-1 in PS3.18 |
|
|
/workitems/1.2.840.10008.5.1.4.34.5/subscribers/{aetitle}{/suspend} |
|
|
/workitems/1.2.840.10008.5.1.4.34.5.1/subscribers/{aetitle}{/suspend} |
Table N.5-137 lists the Header fields supported by the Worklist Web Service user agent for the Suspend Global Subscription Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 8.4.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-137. Header Fields for Worklist Web Service Suspend Global Subscription Transaction - User Agent
The Worklist Web Service origin server supports resources listed in Table N.5-138 for the Suspend Global Subscription Transaction.
Table N.5-138. Resources for Worklist Web Service Suspend Global Subscription Transaction - Origin Server
|
See resource path in Table 11.12.1-1 in PS3.18 |
|
|
/workitems/1.2.840.10008.5.1.4.34.5/subscribers/{aetitle}{/suspend} |
|
|
/workitems/1.2.840.10008.5.1.4.34.5.1/subscribers/{aetitle}{/suspend} |
Table N.5-139 lists the Header fields supported by the Worklist Web Service origin server for the Suspend Global Subscription Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Table 8.4.1-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-139. Header Fields for Worklist Web Service Suspend Global Subscription Transaction - Origin Server
This section provides details regarding the Non-Patient Instance Web Service. For an overview of supported Transactions and resources see Table N.1-11 Non-Patient Instance Service.
The supported Non-Patient Instance Storage SOP Classes are listed in the Table N.5-140 below. The supported Transfer Syntaxes are listed in Section N.1.1 of this document.
[Indicate which SOP Classes are supported by your system. Remove the unsupported ones. See possible NPI SOP Classes in PS 3.4 Table GG.3-1
[Provide requirements for display and processing of instances received via Web Services. This could either be done by referencing Section N.5.2.5.2 if the same requirements apply, or by copying the tables from Section N.5.2.5.2 and filling them appropriately, if requirements for Web Services differ.]
The Non-Patient Instance (NPI) Retrieve transaction as user agent can request resources listed in Table N.5-141
[Provide implementation specific details in the "Comments" column and indicate the supported {npi-name}. They can be:
Table N.5-141. Resources for NPI Web Services Retrieve Transaction - User Agent
|
See resource path in Table 12.4.1-1 in PS3.18 |
|
Table N.5-142 lists the Query parameters supported by the NPI Web Service user agent for the Retrieve Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 12.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-143 lists the Header Fields supported by the NPI Web Service user agent for the Retrieve Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values Section 12.4.1.3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The NPI Web Service origin server supports resources listed in Table N.5-144 for the Retrieve Transaction:
[Provide implementation specific details in the "Comments" column and indicate the supported {npi-name}. They can be:
Table N.5-144. Resources for NPI Web Services Retrieve Transaction - Origin Server
|
See resource path in Table 12.4.1-1 in PS3.18 |
|
Table N.5-145 lists the Query parameters supported by the NPI Web Service origin server for the Retrieve Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 12.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-146 lists the Header Fields supported by the NPI Web Service origin server for the Retrieve Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 12.4.1.3 in PS3.18 and Section 12.4.3.2 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
For details regarding the IODs created by the system, see Section N.9.
The NPI Store Transaction user agent can request resources listed in Table N.5-147.
[List the supported resources. Remove the non-supported resources rows.
Provide implementation specific details in the "Comments" column and indicate what the supported {npi-name} are. They can be:
Table N.5-147. Resources for NPI Web Services Store Transaction - User Agent
|
See resource path in Table 12.5.1-1 in PS3.18. |
|
Table N.5-148 lists the Query parameters supported by the NPI Web Service user agent for the Store Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 12.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-149 lists the Header fields supported by the NPI Web Service user agent for the Store Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 12.5.1.3 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
The NPI Store Transaction origin server receives POST requests to store or append to an existing resource on the server.
The user agent specifies the Target Resource as part of the URI and encapsulates the data in a multipart request body with a proper Content-Type (i.e., BINARY, XML or JSON).
The URI is composed by a Base URI: see Base URI for the origin server in Section N.6.3.4.
The NPI Store Transaction origin server supports resources listed in Table N.5-150.
[List the supported resources. Remove the non-supported resources rows.
Provide implementation specific details in the "Comments" column and indicate what are the supported {npi-name}. They can be:
Table N.5-150. Resources for NPI Web Services Store Transaction - Origin Server
|
See resource path in Table 12.5.1-1 in PS3.18. |
||
Table N.5-151 lists the Query parameters supported by the NPI Web Service origin server for the Store Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Table 12.1.2-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-152 lists the Header fields supported by the NPI Web Service origin server for the Store Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 12.5.1.3 in PS3.18 Fill in information on your implementation in the "Comments" column when necessary.]
The NPI Search Transaction user agent can request resources listed in Table N.5-153.
[Provide implementation specific details in the "Comments" column and indicate what are the supported {npi-name}. They can be:
Table N.5-153. Resources for NPI Web Services Search Transaction - User Agent
|
See resource path in Table 12.6.1-1 in PS3.18. |
|
Table N.5-154 lists the Query parameters supported by the NPI Web Service user agent for the Search Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Section 12.1.2 in PS3.18 and Table 8.3.4-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-155 lists the DICOM query Attributes supported by the NPI Web Service user agent for the Search Transaction.
[Indicate which DICOM query Attributes are supported and if they are supported as Matching and/or Return (include) key. See PS 3.18 Table 12.6.1-2]
Table N.5-156 lists the Header fields supported by the NPI Web Service user agent for the Search Transaction.
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 12.6.1.3 in PS3.18 Fill in information on your implementation in the "Comments" column when necessary.]
The NPI Search Transaction origin server receives GET requests to search for studies, series or instances.
[Specify here if this is a native or a DIMSE proxy implementation.]
The user agent specifies the Target Resource as part of the URI and the acceptable response Content-Type in the HTTP Header (i.e., dicom+xml or dicom+json).
The URI is composed by a Base URI: see Base URI for the origin server in Section N.6.3.4.
The Search Transaction origin server supports resources listed in Table N.5-157.
[Provide implementation specific details in the "Comments" column and indicate the supported {npi-name}. They can be:
Table N.5-157. Resources for NPI Web Services Search Transaction - Origin Server
|
See resource path in Table 12.6.1-1 in PS3.18. |
|
Table N.5-158 lists the Query parameters supported by the NPI Web Service origin server for the Search Transaction.
[List the supported parameters and their supported Values. See possible parameters / Values in Section 12.1.2 in PS3.18 and Table 8.3.4-1 in PS3.18. Fill in information on your implementation in the "Comments" column when necessary.]
[List the supported Header fields and their supported Values. See possible Header fields / Values in Section 12.6.1.3 in PS3.18 and Section 12.6.3.2 in PS3.18 Fill in information on your implementation in the "Comments" column when necessary.]
Table N.5-160 lists the DICOM query / returned Attributes supported by the NPI Web Service origin server for the Search Transaction.
[Indicate which DICOM query Attributes are supported / returned in the response and if they are supported as Matching and/or Return (include) key. See Table 12.6.1-2 in PS3.18]
[If your Web Service supports notification, describe how WebSocket connections are opened. See details in Section 8.10 in PS3.18]
This section provides details regarding the Storage Commitment Web Service. For an overview of suppported Transactions and resources see Table N.1.3.5-1 Storage Commitment Service
The Request Transaction user agent can request resources listed in Table N.5.3.6.1.1-1.
[List the supported resources for your Storage Commitment Request Transaction user agent. Remove the non-supported resources rows. Fill in information on your implementation in the Comments column when necessary.]
Table N.5.3.6.1.1-1. Resources for Request Transaction - User Agent
|
See Resources path in Table 13.1.1-1 in PS3.18 |
|
The Request Transaction user agent supports Header Fields listed in Table N.5.3.6.1.1-2.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
The Request Transaction origin server receives POST requests for storage commitment of the referenced SOP Instances.
The user agent specifies the Target Resource as part of the URI and specifies the UIDs of the SOP Instances as part of the data in the request body with an appropriate Content-Type (i.e., XML or JSON).
The URI is composed by a Base URI: see Base URI for the origin server in Section N.6.3.5.
The Request Transaction origin server supports resources listed in Table N.5.3.6.1.2-1.
[Fill in information on your implementation in the Comments column when necessary.]
Table N.5.3.6.1.2-1. Resources for Request Transaction - Origin Server
|
See Resources path in Table 13.1.1-1 in PS3.18 |
|
The Request Transaction origin server supports Header Fields listed in Table N.5.3.6.1.2-2.
[List the supported Header Fields and their supported Values. Fill in information on your implementation in the "Comments" column when necessary.]
The resources and header fields supported by the user agent for the Result Check Transaction are the same as for the Request Transaction; see Section N.5.3.6.1.1.
The Result Check Transaction origin server receives GET requests to check whether there is a result for a storage commitment request.
The Base URI, resources, and header fields supported by the origin server for the Result Check Transaction are the same as for the Request Transaction; see Section N.5.3.6.1.2.
<Product> supports creating the Basic Directory IOD as a File Set Creator as defined in Section N.9.5.
For a list of supported Media Application Profiles, see Section N.1.4 in the Overview.
For a list of supported SOP Classes, see Section N.1.1 in the Overview.
[Describe, how the File Set Creator is selecting the Media Application Profiles used for creating the Media.]
<Product> supports the Media Application Profiles listed in Section N.1.4 in the Overview.
For a list of supported SOP Classes, see Section N.1.1 in the Overview.
[Provide requirements for display and processing of instances contained on the medium. This could either be done by referencing Section N.5.2.5.2 (as indicated below), if the same requirements apply, or by copying the tables from Section N.5.2.5.2 and filling them appropriately, if requirements for external media differ.]
To display or process DICOM Instances contained on the Media, see Section N.5.2.5.2.
<Product> supports creating the Basic Directory IOD as defined in Section N.9.5.
For a list of supported Media Application Profiles, see Section N.1.4 in the Overview.
For a list of supported SOP Classes, see Section N.1.1 in the Overview.
For a list of supported SOP Classes, see Section N.1.5 in the Overview.
Table N.5-161 lists restrictions that apply to the RTV instances supported by the Service Consumer.
[List the restrictions for the RTV Service Consumer in Table N.5-161 below.]
Table N.5-162 lists the screen resolutions that are supported by the Service Consumer.
[List all supported screen resolutions in Table N.5-162 below.]
[Provide the connection policies including access to the URL to retrieve the SDP object and the number of simultaneous connections.]
For a list of supported SOP Classes, see Section N.1.5 in the Overview.
Table N.5-163 list restrictions that apply to the RTV instances supported by the Service Provider.
[List the restrictions for the RTV Service Consumer in Table N.5-163 below.]
Table N.5-164 list the screen resolutions that are supported by the Service Provider.
[List all supported screen resolutions in Table N.5-164 below.]
[Provide the connection policies including the URL where the Service Consumer can retrieve the SDP object and the number of simultaneous connections.]
This section describes interaction between the implementation of different DICOM Services in this product. Details internal to an individual service are addressed in previous Service Sections.
Note: The DICOM Standard typically does not define cross-service requirements. Therefore, this section provides an implementation description and is not strictly required DICOM Conformance.
[Describe any cross-service interactions, e.g., the MPPS COMPLETED message is sent when the archiving of related Instances in the Study is finished. If there are no Cross Service Considerations remove the text above and mark the section as N/A.]
See Section N.1.7 for supported Values for Specific Character Set (0008,0005).
Generic configuration for Specific Character Sets is covered in . Service specific configuration for Specific Character Sets is addressed in respective subsections of Section N.6.2 or Section N.6.3.
Describe behaviors such as the whether your product sends value 1, e.g.,
This product omits Value 1 of Specific Character Set (0008,0005) when multiple values are present. Per PS3.5, the empty Value 1 indicates usage of ISO 2022 IR 6.]
[Describe the presentation of the characters to a user, i.e., capabilities, font limitations and/or substitutions of characters.]
[If your product supports display/editing of non-default Character Sets, fill in the following table, otherwise remove the following table and introductory text.]
<Product> supports displaying character sets beyond the default character repertoire (ISO-IR 6) for all displayed attributes.
<Product> supports editing character sets beyond the default character repertoire (ISO-IR 6) for the attributes listed in Table N.5-164a.
[If your product supports mapping/conversion of non-default Character Sets, fill in the table below, otherwise remove the table and the introductory text below.]
<Product> supports mapping/conversion of Character Sets as listed in Table N.5-165.
[Describe how Specific Character Sets that are received by the system are mapped to Specific Character Sets sent out by the system. It does not consider the Character Set used internally within the product. In the "Mapping Situation" column describe the scenario in which this mapping occurs, e.g., when mapping Character Sets from a Modality Worklist entry or a Query Retrieve response to the instances created.]
[Explain your product behavior in case it encounters unsupported character sets.]
[Briefly describe if there is a configuration interface (service tool, administration GUI, web interface, or other) to configure the basic parameters.]
Throughout all subsections the following Values can be used in the "Configurable" column:
Table N.6-1 lists general configuration parameters applicable across all supported DICOM Services.
Table N.6-1. General Configuration Parameters
The tables in the following subsections show the configuration parameters required for DIMSE Services.
In order to identify whether <product> is an SCP and/or an SCU, the following applies:
[Use this table template in each supported DIMSE Service section, similar to the example tables provided and provide information as needed for the product implementation. "Local Configuration Parameters" describes parameters for the product described in this DCS, whereas "Remote Configuration Parameters" describes the information needed for this product to interface with a remote system.
Remove rows for any unsupported parameters. For example, if <product> is an SCU only, remove the rows for Called AE Title and Ports in the Local Configuration Parameters part of the table and the Calling AE Title row in the Remote Configuration Parameters part. If <product> is an SCP only, remove the Calling AE Title row in the Local Configuration Parameters part and remove the rows for the Called AE Title, Ports and Host from the Remote Configuration Parameters part.
If your product implementation supports multiple AE Titles for the same service, list all of them in separate rows and describe their use in the "Comments" column.
Table N.6-2 lists Worklist Service configuration parameters:
Table N.6-2. Worklist Service Parameters
Table N.6-3 lists Modality Performed Procedure Step Service configuration parameters:
Table N.6-3. MPPS Service Parameters
Table N.6-4 lists Unified Worklist and Procedure Step Service configuration parameters:
Table N.6-4. Unified Worklist and Procedure Step Service Parameters
Table N.6-5 lists Instance Availability Notification Service configuration parameters:
Table N.6-5. IAN Service Parameters
Table N.6-6 lists Storage Service configuration parameters:
Table N.6-6. Storage Service Parameters
|
[This example shows the configuration for a Storage SCU and SCP, e.g., a PACS.] |
|||
|
List of AE Titles can be configured depending on the usage (study to be verified or not; studies not to be archived; study to be displayed only…) |
|||
|
For studies to be displayed only (not imported in DB/cache, the default port is 110) |
|||
|
See Table N.1-2 |
|||
|
See Table N.1-1 |
|||
|
In case the remote Storage SCU does not send an issuer of Patient ID, you can define a default inbound Patient ID issuer. |
|||
|
In case there are several PID/issuers for the study to send, the default PID/issuer can be selected to be sent as the primary Patient ID to the remote storage SCP |
|||
Table N.6-7 lists Storage Commitment Service configuration parameters:
Table N.6-7. Storage Commitment Service Parameters
Table N.6-8 lists Query/Retrieve Service configuration parameters:
Table N.6-8. Query/Retrieve Service Parameters
Table N.6-9 lists Print Management Service configuration parameters:
Table N.6-9. Print Management Service Parameters
The tables in the following subsections show the configuration parameters required for DICOM Web Services.
To identify whether <product> is an origin server and/or a user agent, the following applies:
["Local Configuration Parameters" describes parameters for the product described in this DCS, whereas "Remote Configuration Parameters" describes the information needed for this product to interface with a remote system. Remove rows for any unsupported parameters]
Table N.6-10 lists the configuration parameters required for URI Web Service.
[Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6-10. URI Web Service Parameters
The Retrieve Transaction is also known as WADO-RS. Table N.6-11 lists configuration parameters for the Retrieve Transaction of the Studies Web Service:
[Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6-11. Retrieve Transaction Parameters
The Store Transaction is also known as STOW-RS. Table N.6-12 lists configuration parameters for the Store Transaction of the Studies Web Service:
[Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6-12. Store Transaction Parameters
The Search Transaction service is also known as QIDO-RS. Table N.6-13 lists configuration parameters for the Search Transaction of the Studies Web Service:
[Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6-13. Search Transaction Parameters
The Worklist Web Service is also known as UPS-RS.
Table N.6-14 lists the configuration parameters for the Worklist Web Service.
[Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6-14. Worklist Web Service Parameters
Table N.6-15 lists the configuration parameters for the NPI Web Service.
[ Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6-15. NPI Web Service Parameters
Table N.6.3.5-1 lists configuration parameters for the Request Transaction of the Storage Commitment Service:
[Remove the unsupported parameters from the local and remote configuration parameters.]
Table N.6.3.5-1. Request and Result Check Transaction Parameters
Table N.6.3.5-1 lists configuration parameters for the Result Check Transaction of the Storage Commitment Service.
Table N.6-16 lists configuration parameters for the Media Storage service.
Table N.6-17 lists configuration parameters for the Real-Time Video service.
Table N.6-17. RTV Service Parameters
[If your system is only an originator remove the Collector Parameters Table.]
[If your system is only a collector remove the Originator Parameters Table.]
[If your system is both an originator and a collector, keep both tables and indicate if it is a relay.]
Table N.6-18 lists configuration parameters for the Audit Trail Originator.
Table N.6-18. Audit Trail Originator Parameters
Table N.6-19 lists configuration parameters for the Audit Trail Collector.
Table N.6-19. Audit Trail Collector Parameters
The cross interaction between the AEs is depicted in the diagrams below.
[Shown below are some examples of cross AE interactions. Modify them to match your product implementation.]
Table N.7-1 lists Association parameters applicable to all AEs on the system.
[If the Association parameters for your system are the same across all AEs, fill in the table below and mark the respective sections for AE specific Association parameters as N/A. If your system uses different Association parameters for each AE replace the content of this section with N/A and append N/A to the section heading.]
Table N.7-1. General Association Parameters
[Describe the messaging sequence of AE for a Real-World activity that is performed.
E.g.: Local Real-World Activity <2> first open an Association, triggers message <a> and message <b> on this Association before closing it. Action <c> is then performed on the system before Local Real-World Activity <1> can be launched to send message <d> on a new Association and receives message <e> on the same Association.]
[Also include its use of DICOM Web Services, including any proxy functionality between a Web Service and the equivalent DIMSE Service here.
Also include its use of DICOM-RTV Services, including any proxy functionality between a DICOM-RTV and another service provided through DIMSE Service or RESTful (i.e., storage of received video and audio with associated metadata).
[Below are examples for a Query Retrieve AE and a Web AE. Modify as applicable for your product implementation.]
Table N.7-2 lists Association parameters applicable to <AE1.>
[If your system uses different Association parameters for each AE fill in the table below for each AE and mark this section as N/A.]
Table N.7-2. Association Parameters for <AE1>
This section details the Association policies of the Application Entity when it is initiating an Association.
[For each Real-World Activity of AE1 provide subsections Section N.7.2.1.3, “Association Initiation”.x.]
[Describe the policies for creating Associations. Include the following details:
[Describe the actions and behavior that cause the product to issue N-ACTION requests and how it relates to the previous storage request, e.g., is the storage commitment initiated right after a successful C-STORE, or is the storage commitment issued after all instance in the study have been successfully stored, …]
[Describe the Association initiation behavior of your product with regards to the N-EVENT-REPORT request, e.g., whether the N-EVENT-REPORT request is sent on the same Association or whether it is initiated on a different Association.]
[Describe your system behavior if your product cannot establish an Association with the SCU, e.g., is there a retry mechanism, is that configurable, …]
The Extended Negotiation parameters for all services that are supported by the Application Entity for the Real-World Activity <Activity 1> are described in Table N.7-3.
[Describe below all the Extended Negotiation that the Application Entity requests for the <Activity 1> during Association negotiation. Use "Y" in the "Support" column to indicate support for Extended Negotiation or "N" to indicate that Extended Negotiation is not supported, and the default Value is sent in the Association field. Describe any behavior pertaining to handling extended behavior during Association initiation under this section.]
[Modify the table below to reflect the services participating in <Activity 1>.]
Table N.7-3. Extended Negotiation for <Activity 1> of <AE1> - Association Initiation
|
Applicable to all Storage SOP Classes listed under Section N.5. |
|||
|
Applicable to all Query Retrieve - FIND SOP Classes mentioned under Section N.5. |
|||
|
Applicable to all Query Retrieve - MOVE SOP Classes mentioned under Section N.5. |
|||
[Describe if the AE supports Role Negotiation in the case of Storage commitment happening synchronously i.e., if the N-ACTION and the N-EVENT-REPORT are performed in the same Association.]
This section details the Association policies of the Application Entity when it is the acceptor of an Association.
[For each Real-World Activity of AE1 provide subsections Section N.7.2.1.4, “Association Acceptance”.x.]
[Describe the service specific Association acceptance behavior of your product, e.g.
The Extended Negotiation parameters for all services that are requested by the Application Entity for the Real-World Activity <Activity 2> are described in Table N.7-4.
[Describe below all the Extended Negotiation that the Application Entity supports for <Activity 2> during Association negotiation. Use "Y" in the "Support" column to indicate support for Extended Negotiation or "N" to indicate that Extended Negotiation is not supported, and the default Value is sent in the Association field. Describe any behavior pertaining to handling extended behavior during Association acceptance under this section.]
[Modify the table below to reflect the services participating in <Activity 2>.]
Table N.7-4. Extended Negotiation for <Activity 2> of <AE1> - Association Acceptance
|
Applicable to all Storage SOP Classes listed under Section N.5. |
|||
|
Applicable to all Query Retrieve - FIND SOP Classes mentioned under Section N.5. |
|||
|
Applicable to all Query Retrieve - MOVE SOP Classes mentioned under Section N.5. |
|||
Transfer Syntax Selection Policies
This section provides tables that describe the Transfer Syntax preference for different SOP Classes or SOP Class groups when there are multiple Transfer Syntaxes provided by the Association initiator for Real-World Activity <Activity 2> of <AE1> of the system.
[The preference for Transfer Syntax selection is based on the type of data i.e., Image SOP Classes, Video SOP Classes or non-image/video SOP Classes.]
[Edit the tables below to indicate the transfer selection polices applicable to the documented activity.
If there are exceptions to the standard preference SOP Classes, mention this in the "Comments" column.
If the preference order is based on some other criteria, add another table.]
Table N.7-5. Transfer Syntax Selection Preference Order - Image SOP Classes for <AE1>
The following sections describe the Status Codes supported by the system for each implemented service as well as the reason for issuing specific Status Codes or the associated behavior when receiving it.
[Throughout all SCP related subsections, if necessary provide in the "Condition" Column further information (beyond the information in the "Further Meaning" Column) on the specific situation/condition, in which the respective Status Code is sent. E.g. for the Status Code
Table N.7-8 describes behavior of the AE if a communication failure occurs when it initiated an Association.
[Describe below the behavior of the AE if a communication failure occurs when it initiated an Association, e.g.: Timeout, Network disconnect ABORT etc.]
Table N.7-8. DICOM Communication Failure Behavior as Association Initiator
Table N.7-9 describes how the AE responds when it receives an Association request that leads to a failure in communication.
[Describe how the AE responds when it receives Association requests that leads to a failure in communication: application error during processing, unrecognized PDU values in the Association request etc. List all cases supported by the product.]
Table N.7-9. DICOM Communication Failure Handling as Association Acceptor
Table N.7-10 lists the Status Codes that the SCU of the Modality Worklist Information Model Find SOP Class supports for the C-FIND message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-10. Status Codes for C-FIND of the Modality Worklist Information Model SOP Class - SCU
Table N.7-11 lists the Status Codes that the SCP of the Modality Worklist Information Model Find SOP Class supports for the C-FIND message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-11. Status Codes for C-FIND of the Modality Worklist Information Model SOP Class - SCP
Table N.7-12 lists the Status Codes that the SCU of the Modality Performed Procedure Step SOP Class supports for the N-CREATE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.]
[In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-13 lists the Status Codes that the SCU of the Modality Performed Procedure Step SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-14 lists the Status Codes that the SCP of the Modality Performed Procedure Step SOP Class supports for the N-CREATE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-15 lists the Status Codes that the SCP of the Modality Performed Procedure Step SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-16 lists the Status Codes that the SCU of the UPS Push SOP Class supports for the N-CREATE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-16. Status Codes for N-CREATE of the UPS Push SOP Class - SCU
Table N.7-17 lists the Status Codes that the SCU of the Request UPS Cancel on UPS Push SOP Class supports for the N-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-17. Status Codes for N-ACTION of the UPS Push SOP Class Request UPS Cancel - SCU
Table N.7-18 lists the Status Codes that the SCU of the UPS Push SOP Class supports for the N-GET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-18. Status Codes for N-GET of the UPS Push SOP Class - SCU
Table N.7-19 lists the Status Codes that the SCU of the UPS Pull SOP Class supports for the C-FIND message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-19. Status Codes for C-FIND of the UPS Pull SOP Class - SCU
Table N.7-20 lists the Status Codes that the SCU of the UPS Pull SOP Class supports for the N-GET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-20. Status Codes for N-GET of the UPS Pull SOP Class - SCU
Table N.7-21 lists the Status Codes that the SCU of the UPS Pull SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-21. Status Codes for N-SET of the UPS Pull SOP Class - SCU
Table N.7-22 lists the Status Codes that the SCU of the Change UPS State of UPS Pull SOP Class supports for the N-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-22. Status Codes for N-ACTION of the UPS Pull SOP Class - SCU
Table N.7-23 lists the Status Codes that the SCU of the Un/Subscribe of the UPS Watch SOP Class supports for the N-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-23. Status Codes for N-ACTION (Subscribe/Unsubscribe) of the UPS Watch SOP Class - SCU
Table N.7-24 lists the Status Codes that the SCU of the UPS Watch SOP Class supports for the N-GET message and defines the application behavior when encountering any the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-24. Status Codes for N-GET of the UPS Watch SOP Class - SCU
Table N.7-25 lists the Status Codes that the SCU of the UPS Watch SOP Class supports for the C-FIND message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-25. Status Codes for C-FIND of the UPS Watch SOP Class - SCU
Table N.7-26 lists the Status Codes that the SCU of the Request UPS Cancellation on UPS Watch SOP Class supports for the C-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-26. Status Codes for N-ACTION (Request Cancel) of the UPS Watch SOP Class - SCU
Table N.7-27 lists the Status Codes that the SCU of the UPS Event SOP Class supports for the N-EVENT-REPORT message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-28 lists the Status Codes that the SCP of the UPS Push SOP Class supports for the N-CREATE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-28. Status Codes for N-CREATE of the UPS Push SOP Class - SCP
Table N.7-29 lists the Status Codes that the SCP of the UPS Push SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-29. Status Codes for N-ACTION (Request Cancel) of the UPS Push SOP Class - SCP
Table N.7-30 lists the Status Codes that the SCP of the UPS Push SOP Class supports for the N-GET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-30. Status Codes for N-GET of the UPS Push SOP Class - SCP
Table N.7-31 lists the Status Codes that the SCP of the UPS Pull SOP Class supports for the C-FIND message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-31. Status Codes C-FIND of the UPS Pull SOP Class - SCP
Table N.7-32 lists the Status Codes that the SCP of the UPS Pull SOP Class supports for the N-GET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-32. Status Codes for N-GET of the UPS Pull SOP Class - SCP
Table N.7-33 lists the Status Codes that the SCP of the UPS Pull SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-33. Status Codes for N-SET of the UPS Pull SOP Class - SCP
Table N.7-34 lists the Status Codes that the SCP of the Change UPS State of the UPS Pull SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-34. Status Codes for N-ACTION (change state) of the UPS Pull SOP Class - SCP
Table N.7-35 lists the Status Codes that the SCP of the Un/Subscribe on the UPS Watch SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-35. Status Codes for N-ACTION (Subscribe/Unsubscribe) of the UPS Watch SOP Class - SCP
Table N.7-36 lists the Status Codes that the SCP of the UPS Watch SOP Class supports for the N-GET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-36. Status Codes for N-GET of the UPS Watch SOP Class - SCP
Table N.7-37 lists the Status Codes that the SCP of the UPS Watch SOP Class supports for the C-FIND message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-37. Status Codes C-FIND of the UPS Watch SOP Class - SCP
Table N.7-38 lists the Status Codes that the SCP of the Request UPS Cancellation on UPS Watch SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-38. Status Codes for N-ACTION (Request Cancel) of the UPS Watch SOP Class - SCP
Table N.7-39 lists the Status Codes that the SCP of the UPS Event SOP Class supports for the N-EVENT-REPORT message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-40 lists the Status Codes that the SCU of the Instance Availability Notification SOP Class supports for the N-CREATE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-41 lists the Status Codes that the SCP of the Instance Availability Notification SOP Class supports for the N-CREATE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-42 lists the Status Codes that the SCU of the Storage SOP Class supports for the C-STORE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-43 lists the Status Codes that the SCP of the Storage SOP Classes supports for the C-STORE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
[List the Attributes that are used to further detail the Status Codes in the "Related Fields Columns". Use N/A if there are no related fields used.Further comments regarding the Related Fields can be provided in the "Condition" Column]
Table N.7-44 lists the Status Codes that the SCU of the Storage Commitment Push Model SOP Class supports for the N-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-45 lists the Status Codes that the SCU of the Storage Commitment Push Model SOP Class supports for the N-EVENT-REPORT message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-46 lists the Status Codes that the SCP of the Storage Commitment Push Model SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-47 lists the Status Codes that the SCP of the Storage Commitment Push Model SOP Class supports for the N-EVENT-REPORT message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-48 lists the Status Codes that the SCU of any of the Query/Retrieve FIND SOP Class supports for the C-FIND message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-48. Status Codes C-FIND for Query/Retrieve FIND SOP Classes - SCU
Table N.7-49 lists the Status Codes that the SCU of any of the Query/Retrieve MOVE SOP Class supports for the C-MOVE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-50 lists the Status Codes that the SCP of any of the Query/Retrieve FIND SOP Classes supports for the C-FIND message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-50. Status Codes C-FIND for Query/Retrieve FIND SOP Classes - SCP
Table N.7-51 lists the Status Codes that the SCP of any of the Query/Retrieve MOVE SOP Classes supports for the C-MOVE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
[Describe the action on the C-STORE sub-operation due to above mentioned conditions. Mention what happens to the C-STORE sub-operation when the specific condition occurs.]
Table N.7-52 lists the Status Codes that the SCU of the Basic Film Session SOP Class supports for the N-CREATE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-53 lists the Status Codes that the SCU of the Basic Film Session SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-54 lists the Status Codes that the SCU of the Basic Film Session SOP Class supports for the N-DELETE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-55 lists the Status Codes that the SCU of the Basic Film Session SOP Class supports for the N-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-55. Status Codes for N-Action of the Basic Film Session SOP Class - SCU
Table N.7-52 lists the Status Codes that the SCU of the Basic Film Box SOP Class supports for the N-CREATE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-56. Status Codes for N-CREATE of the Basic Film Box SOP Class - SCU
Table N.7-57 lists the Status Codes that the SCU of the Basic Film Box SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-57. Status Codes for N-SET of the Basic Film Box SOP Class - SCU
Table N.7-58 lists the Status Codes that the SCU of the Basic Film Box SOP Class supports for the N-DELETE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-59 lists the Status Codes that the SCU of the Basic Film Box SOP Class supports for the N-ACTION message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-59. Status Codes for N-ACTION of the Basic Film Box SOP Class - SCU
Table N.7-60 lists the Status Codes that the SCU of the Basic Grayscale Image Box SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-60. Status Codes for N-SET of the Grayscale Image Box SOP Class - SCU
Table N.7-61 lists the Status Codes that the SCU of the Basic Color Image Box SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-61. Status Codes for N-SET of the Color Image Box SOP Class - SCU
Table N.7-62 lists the Status Codes that the SCU of Printer SOP Class supports for the N-EVENT-REPORT message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-63 lists the Status Codes that the SCU of the Printer SOP Class supports for the N-GET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-64 lists the Status Codes that the SCU of the Basic Annotation Box SOP Class supports for the N-SET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-65 lists the Status Codes that the SCU of the Print Job SOP Class supports for the N-EVENT-REPORT message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. If any other Status Code is supported add it to the table.] In the "other Status Codes" row document the behavior of the application in case it encounters and unknown Status Code.]
Table N.7-66 lists the Status Codes that the SCU of Print Job SOP Class supports for the N-GET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-67 lists the Status Codes that the SCU of the Presentation LUT SOP Class supports for the N-CREATE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-67. Status Codes N-CREATE of the Presentation LUT SOP Class - SCU
Table N.7-68 lists the Status Codes that the SCU of the Presentation LUT SOP Class supports for the N-DELETE message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-69 lists the Status Codes that the SCU of the Printer Configuration SOP Class supports for the N-GET message and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-70 lists the Status Codes that the SCP of the Basic Film Session SOP Class supports for the N-CREATE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-71 lists the Status Codes that the SCP of the Basic Film Session SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-72 lists the Status Codes that the SCP of the Basic Film Session SOP Class supports for the N-DELETE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-73 lists the Status Codes that the SCP of the Basic Film Session SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-73. Status Codes for N-ACTION of the Basic Film Session SOP Class - SCP
Table N.7-74 lists the Status Codes that the SCP of the Basic Film Box SOP Class supports for the N-CREATE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-74. Status Codes for N-CREATE of the Basic Film Box SOP Class - SCP
Table N.7-75 lists the Status Codes that the SCP of the Basic Film Box SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-75. Status Codes for N-SET of the Basic Film Box SOP Class - SCP
Table N.7-76 lists the Status Codes that the SCP of the Basic Film Box SOP Class supports for the N-DELETE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-77 lists the Status Codes that the SCP of the Basic Film Box SOP Class supports for the N-ACTION message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-77. Status Codes for N-ACTION of the Basic Film Box SOP Class - SCP
Table N.7-78 lists the Status Codes that the SCP of the Basic Grayscale Image Box SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-78. Status Codes for N-SET of the Basic Grayscale Image Box SOP Class - SCP
Table N.7-79 lists the Status Codes that the SCP of the Basic Color Image Box SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-79. Status Codes for N-SET of the Basic Color Image Box SOP Class - SCP
Table N.7-80 lists the Status Codes that the SCP of the Printer SOP Class supports for the N-EVENT-REPORT message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-81 lists the Status Codes that the SCP of the Printer SOP Class supports for the N-GET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-82 lists the Status Codes that the SCP of the Basic Annotation Box SOP Class supports for the N-SET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-83 lists the Status Codes that the SCP of the Print Job SOP Class supports for the N-EVENT-REPORT message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-84 lists the Status Codes that the SCP of the Print Job SOP Class supports for the N-GET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-85 lists the Status Codes that the SCP of the Presentation LUT SOP Class supports for the N-CREATE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-85. Status Codes for N-CREATE of the Presentation LUT SOP Class - SCP
Table N.7-86 lists the Status Codes that the SCP of the Presentation LUT SOP Class supports for the N-DELETE message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-87 lists the Status Codes that the SCP of the Printer Configuration SOP Class supports for the N-GET message and defines conditions in which the listed Status Codes are sent.
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
This section describes the common Status Code behavior and handling all the supported transaction.
Table N.7-88 lists the Status Codes that an origin server supports for all transactions and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-89 lists the Status Codes that a user agent supports for all transactions and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-90 lists the Status Codes that an origin server supports for the URI Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-91 lists the Status Codes that a user agent supports for the URI Web Service and defines the application behavior when encountering the listed Status Codes.
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-92 lists the Status Codes that an origin server supports for the Retrieve Transaction of the Studies Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-93 lists the Status Codes that a user agent supports for the Retrieve Transaction of the Studies Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-94 lists the Status Codes that an origin server supports for the Store Transaction of the Studies Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-95 lists the Status Codes that a user agent supports for the Store Transaction of the Studies Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-96 lists the Status Codes that an origin server supports for the Search Transaction of the Studies Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-97 lists the Status Codes that a user agent supports for the Search Transaction of the Studies Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-98 lists the Status Codes that an origin server supports for the Create Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-99 lists the Status Codes that a user agent supports for the Create Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-100 lists the Status Codes that an origin server supports for the Retrieve Workitem Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-101 lists the Status Codes that a user agent supports for the Retrieve Workitem Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-102 lists the Status Codes that an origin server supports for the Update Workitem Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-103 lists the Status Codes that a user agent supports for the Update Workitem Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-104 lists the Status Codes that an origin server supports for the Change Workitem State Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-105 lists the Status Codes that a user agent supports for the Change Workitem Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-106 lists the Status Codes that an origin server supports for the Request Cancellation of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-107 lists the Status Codes that a user agent supports for the Request Cancellation Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-108 lists the Status Codes that an origin server supports for the Search Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-109 lists the Status Codes that a user agent supports for the Search Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-110 lists the Status Codes that an origin server supports for the Subscribe Transaction of the Worklist Web Service and the conditions in which the listed Status Codes is sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-111 lists the Status Codes that a user agent supports for the Subscribe Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-112 lists the Status Codes that an origin server supports for the Unsubscribe Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-113 lists the Status Codes that a user agent supports for the Unsubscribe Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-114 lists the Status Codes that an origin server supports for the Suspend Global Subscription Transaction of the Worklist Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-115 lists the Status Codes that a user agent supports for the Suspend Global Subscription Transaction of the Worklist Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-116 lists the Status Codes that an origin server supports for the Retrieve Transaction of the Non-Patient Instance Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-117 lists the Status Codes that a user agent supports for the Retrieve Transaction of the Non-Patient Instance Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-118 lists the Status Codes that an origin server supports for the Store Transaction of the Non-Patient Instance Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-119 lists the Status Codes that a user agent supports for the Store Transaction of the Non-Patient Instance Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7-120 lists the Status Codes that an origin server supports for the Search Transaction of the Non-Patient Instance Web Service and the conditions in which the listed Status Codes are sent:
[Describe the condition which causes the application to send the specific Status Codes. For each other Status Code used add a row to the table.]
Table N.7-121 lists the Status Codes that a user agent supports for the Search Transaction of the Non-Patient Instance Web Service and defines the application behavior when encountering the listed Status Codes:
[Describe the behavior of the application when it receives any of the Status Codes listed in the table below, e.g., displaying and logging the error code or retrying the request. For each additional Status Code supported add a row to the table.
In the "Other Status Codes" row document the behavior of the application in case it encounters an unknown Status Code.]
Table N.7.3.3.6.1-1 lists the Status Codes that an origin server supports for the Request Transaction of the Storage Commitment Service and the condition in which any of the listed Status Codes is sent.
[Describe below the condition in which the application sends the specific Status Codes in the Request Transaction response as origin server.]
Table N.7.3.3.6.1-1. Status Codes of Origin Server for Request Transaction
Table N.7.3.3.6.2-1 lists the Status Codes that a user agent supports for the Request Transaction of the Storage Commitment Service and defines the application behavior, when encountering any of the listed Status Codes.
[Describe below the behavior of the application when it receives various Status Codes in the Request Transaction response.]
Table N.7.3.3.6.2-1. Status Codes of User Agent for Request Transaction
Table N.7.3.3.6.3-1 lists the Status Codes that an origin server supports for the Result Check Transaction of the Storage Commitment Service and the condition in which any of the listed Status Codes is sent.
[Describe below the condition in which the application sends the specific Status Codes in the Result Check Transaction response as origin server.]
Table N.7.3.3.6.3-1. Status Codes of Origin Server for Result Check Transaction
Table N.7.3.3.6.4-1 lists the Status Codes that a user agent supports for the Result Check Transaction of the Storage Commitment Service and defines the application behavior when encountering any of the listed Status Codes.
[Describe below the behavior of the application when it receives various Status Codes in the Result Check Transaction response.]
Table N.7.3.3.6.4-1. Status Codes of User Agent for Result Check Transaction
[This section contains several subsections that describe information that may already be present in other security documents (e.g., MDS2 statement). For each subsection, you can therefore either fill it in or remove it and reference a security document if all requested information is present in the referenced document.]
The security section describes security features implemented by this product. It includes descriptions of non-DICOM network protocols, information to configure firewalls and application whitelists, lists of supported DICOM security profiles as well as Web Security features. Additionally, secured media storage, VPN, etc. are also specified in this security section.
Table N.8-1 describes additional non-DICOM network protocols that are used by <Product>.
[From this table, delete any Profiles/Actors/Transactions that are not supported at all.If the Profile is supported using a secure mechanism use Y for yes in the "Security Support" column, otherwise use N for No.]
See Section N.6 Configuration for information on the usage of ports for DICOM and other protocols. This section contains helpful information for product administrators to configure firewalls, application whitelists, etc.
[It is advised to make sure enough information is provided to support security configuration. For example, for Firewall configuration, list all other non-DICOM ports and/or provide a reference to any other security document that may be useful for the reader.]
Table N.8-2 lists the Secure Use and User Identity Profiles:
[In Table N.8-2 below, all the Profiles not supported can be deleted. But it is also permitted to keep them for transparency reasons and mark them with "N".]
[In Table N.8-3 below, all the Profiles not supported can be deleted. But it is also permitted to keep them for transparency reasons and mark them with "N".
In the "Secured AE" column list the AEs that support the Profile (use ALL if all AEs support it, ALL EXCEPT to provide an exception list). In the "Sender" and "Receiver" columns, describe if the Profile is supported or not using Y or N.]
Table N.8-3 describes the Secure Transport Connection Profiles supported by the product. Accepted cipher suites are described in the section listed in the "Reference" column.
See Section N.1.4 Media Services for information on supported secured Application Profiles and secured media.
Table N.8-4 details the encryption mechanisms that are supported with secure media.
[In Table N.8-4, all the Profiles not supported can be deleted. But it is also permitted to keep them for transparency reasons and mark them with "N".]
[In Table N.8-5, all the Profiles not supported can be deleted. But it is also permitted to keep them for transparency reasons and mark them with "N".]
[In Table N.8-6, all the Profiles not supported can be deleted. But it is also permitted to keep them for transparency reasons and mark them with "N".]
Table N.8-7 lists supported Attribute Confidentiality Profiles and options:
[In Table N.8-7 all the Profiles not supported can be deleted. But it is also permitted to keep them for transparency Reasons and mark them with "N".
Add any private option and/or private profiles. For each option, indicate in the "AE" column the list of AEs that support the option (Use ALL if all AEs support it, ALL EXCEPT to provide an exception list). In remaining columns, indicate whether the option is supported as de-identifier, as re-identifier and if some configurability can be performed in the way anonymization can be applied.]
Table N.8-7. Attribute Confidentiality Profiles
[Describe here the general strategy that applies to the product for new Attributes that could be defined later in the standard. Will they be kept, removed or can the behavior be configured? If configurable, does the configuration apply to all new elements or will it be configurable on a data element per data element basis?]
See Section N.11.2.6 for implementation details.
[List here any Digital Signature Profile that your product may support. Also document the details of the supported profiles in Section N.11.2.7. Mark this section as N/A if your product does not support any Digital Signature profile.]
[If your product does not support any User Identity Negotiation, mark this section as N/A and delete subsections.]
Table N.8-8 lists User Identity Negotiation support as Association Initiator:
[In the following table, if your product supports User Identity Negociation as an Association Initiator, use Y for yes in the "Supported" column, otherwise use N for No. For each supported field, indicate the list of values that are supported in the "Requested Value" column.]
[If your product implements User Identity Negotiation without supporting a User Identity profile listed in Section N.8.4.1, describe here additional encryption, MAC and signature algorithms that your product supports beyond the minimal requirements specified in RFC 7519 (e.g., for support of JSON Web Token (JWT) - User identity type=5).]
Table N.8-9 lists User Identity Negotiation support as Association Acceptor:
[In the following table, if your product supports User Identity Negotiation as an Association Acceptor, use Y for yes in the "Supported" column and indicate the list of values that are supported in the "Requested Value" column, otherwise use N for No.]
[Describe here how your product supports User Identity negotiation to authenticate the user and rules applied to this authentication. If this information is provided in an external document, provide the reference to this document in this section instead.]
[Describe in this section the security mechanisms utilized by the implementation. In particular (but not limited to), consider:
These descriptions may be just a reference to another section of the Conformance Statement if these mechanisms are common with DICOM networking services described before or may contain references to other relevant documentation.]
[Describe in the following subsections any additional security features not covered in previous sections that your product may support.]
[Describe here any support of additional media storage security features such as encrypted media. Put "N/A" if none.]
[Describe here any support additional network security features such as VPN, etc. Put "N/A" if none.]
[Describe here any additional supported security features not described in previous sub-sections such as physical security features (access card, tokens, two factor authentications, OAuth, IHE IUA Profile etc.). If available, you can also provide a link to MDS2 statements applicable to the various AEs of this product here. Put "N/A" if none.]
[In an actual DICOM Conformance Statement Section N.9 to Section N.13 should be numbered Annex A to Annex E.]
[Note that the Annexes defined in the following subsections are a mandatory part of the DICOM Conformance Statement and must be filled for any product that creates DICOM objects.]
[For all SOP Instances of supported Storage SOP Classes (including Real-Time Video objects) that can be created by the system (see Overview Section N.1.1) provide an Annex A.x.]
[Throughout all the tables in this Annex, the Tag order is as it appears in the DICOM Standard to ease comparison and validation. It is recommended that products do the same in their Conformance Statements.]
This section describes all the SOP Instances natively created by <Product>, e.g., images created by an acquisition modality or evidence documents created on a review workstation (i.e., all SOP Classes that are marked in the "Created" column in Table N.1-1). Details on Attribute coercion are defined in Section N.5.2.5.2.
In the "Source" column, the following Values can be used:
CONFIGURATION: The Value is copied from the system configuration.
QUERY: The Value is determined by performing a query of any of the supported Query/Retrieve Services.
SCANNED: The Value is read from a barcode scanner or similar device.
SRC_INSTANCE: The Value is copied from previously created/received SOP Instances.
The "Presence" columns reflect the usage of the Module, Functional Group Macro, Attributes, or Value in the <product>Implementation and is not necessarily the same as defined in the DICOM Standard. For the "Presence" column the following Values can be used:
ALWAYS: the module, functional group macro, Attributes or Value is always present.
CONDITIONAL: the presence of the module, functional group macro, Attributes or Value is dependent on a condition. The condition must be listed in the "Conditions" column.
SRC_COPY: The presence of the Attributes and Values depends on the availability of these in the source instances, which are used for copying this information.
EMPTY: The Attribute is present but without a Value (zero length).
All SOP Instances generated by the system use the common modules listed in Table N.9-1 to Table N.9-12 or a subset of them, as defined in the IOD specific subsections below.
[The tables list the most common Modules; tables for additional Modules can be appended at the end. It is up to the editor of the DICOM Conformance Statement to move some of the tables to the IOD specific sections, if the information differs between the documented IODs.]
[Complete the following tables and provide information on all Attributes that are populated in your IOD, add additional Attributes, remove Attributes not used and provide a description how the Attributes are populated.]
[For the "Source" column use one of the pre-defined terms above, also note that multiple Values are allowed, however an explanation of the conditions under which one or the other Value is used, must be provided.]
[If in the "Value" column different Values are supported, they can be defined in the Shared Values and Code Set subsection and a reference to the respective table can be entered in the "Value" column. Furthermore, for Coded Terms it is possible to provide a reference to a CID defined in PS3.16.]
[For the "Presence" columns the Values defined above can be used. Also note that multiple Values are allowed, however an explanation of the conditions under which one or the other Value is used, must be provided.]
[If the modules use Attributes that can support different Value Types (See PS3.15), add the Value Type supported in the "Comments" column.]
Table N.9-9. Multi-Frame Functional Groups Module
[If your product uses other Modules that are shared between multiple IODs created on your product, list them in tables following the structure of the above ones.]
The tables below list the Common Functional Group Macros that can either be used as part of the Shared Functional Groups Sequence (5200,9229) or as part of the Per-frame Functional Groups Sequence (5200,9230) of enhanced image IODs.
[Modify/add/delete tables below to match your product implementation. For content of the columns, see the instructions in A.1.1 Common Modules:
If you do not create any enhanced IODs mark this section as N/A, append "-N/A" to the Section Title and remove the tables below.]
The tables below list private Attributes that are used in multiple IODs generated by the system. For documentation convenience and readability, they are organized in modules, although the concept of modules does not exist in the standard for private Attributes.
[For each Common Private Module create a table following the structure listed below and populate it with all private Attributes which are shared between different IODs. For each Attribute list name, Tag, Value Representation, Value Multiplicity, whether the Value contains Identifiable Information). In the "Identifiable Information" column the following Values can be used: SAFE, UNSAFE, MIXED. For details see the Private Data Element Characteristics Sequence (0008,0300) as defined in DICOM PS3.3.
For the other columns see the instructions above. It is highly recommended to populate the Private Data Element Characteristics Sequence (0008,0300) if Private Attributes are being used.]
[For a description of the purpose of the Private Attribute either use the "Comments" column or add a note below the table.]
Table N.9-22 lists Coded Values referenced from the "Value" column of the tables above.
[Document Coded Terms and Code String values in the following table. Coded Terms must be documented as (Code Value, Coding Scheme Designator, "Code Meaning".]
Table N.9-23 defines the structure of <Image IOD 1>.
[Provide a list of all Modules, their presence, conditions in which they will be present and a reference to a table with the detailed module description. Below is an example for a CT Image IOD.]
The following tables list Modules and Attributes specific for <Image IOD 1>:
[List all IOD specific Modules in a separate table following the structure defined below, their Attributes, Values, usage, and conditions in the table below. For instructions on the content of the columns see instructions in SectionA.A Information Object Definitions (IODs).]
Table N.9-26 lists private Modules and Attributes for < Image IOD 1>:
[List all private Attributes added specifically for this IOD here. Mark this section as N/A if there are none. If the description gets too long, you can add footnotes under the table.]
Table N.9-27 lists Coded Values referenced from the "Value" column of the tables above for <Image IOD 1>:
[Document Coded Terms and Code String values in the following table. Coded Terms must be documented as (Code Value, Coding Scheme Designator, "Code Meaning".]
Table N.9-28 defines the structure of <Image IOD 2>.
[Provide a list of all Modules, their presence, conditions in which they will be present and a reference to a table with the detailed module description. Below is an example for a Enhanced Computed Tomography Image IOD.]
Table N.9-29 lists the Functional group macros used in <Image IOD2>. The "Usage" column defines whether a Macro is used as a shared Macro, on a per frame base or whether depending on the acquisition context can be used in both contexts. The following Values are supported:
PER_FRAME: The macro is used on a per frame basis, the Attributes are included in the Per-frame Functional Groups Sequence (5200,9230)
SHARED: The macro is shared across all frames; the Attributes are included in the Shared Functional Groups Sequence (5200,9229)
CONTEXT_DEPENDENT: Depending on the acquisition context the macro can either be used on a per frame basis or be shared across all frames.
[Provide a list of all functional group macros, their presence, conditions in which they will be present and a reference to a table with the detailed macro description.]
Table N.9-29. Functional Group Macros used in < Image IOD 2>
The following tables list Modules and Attributes specific for <Image IOD 2>:
[List all IOD specific Modules in a separate table following the structure defined below, their Attributes, Values, usage, and conditions in the table below. For instructions on the content of the columns see instructions in SectionA.A Information Object Definitions (IODs).]
The tables below list functional group macros and Attributes for <Image IOD 2>:
[For enhanced objects provide the list of IOD specific shared Functional Group Macros and per-frame Functional Group Macros. Create one table for each supported Functional Group Macro using the structure defined below.]
[List all private Attributes added specifically for this IOD here. Mark this section as N/A if there are none.]
Table N.9-44 lists Coded Values referenced from the "Value" column of the tables above for <Image IOD 2>:
[Document Coded Terms and Code String values in the following table. Coded Terms must be documented as (Code Value, Coding Scheme Designator, "Code Meaning".]
Table N.9-45 defines the structure of <SR IOD 1>.
[Provide a list of all Modules, their presence, conditions in which they will be present and a reference to a table with the detailed module description. Below is an example for a Comprehensive SR IOD.]
The tables below list modules and Attributes used in <SR IOD1>:
[List all IOD specific Modules in a separate table following the structure defined below, their Attributes, Values, usage, and conditions in the Table below. For instructions on the content of the columns see instructions in SectionA.A Information Object Definitions (IODs).]
Table N.9-46. SR Document Series Module used in <SR IOD 1>
|
(See Section N.12 for details) |
See Section N.12 |
||||||
Table N.9-48. SR Document Content Module used in <SR IOD 1>
|
See Section N.10 for encoding on supported TIDs |
[List all private Attributes added specifically for this IOD here. Mark this section as N/A if there are none.]
Table N.9-49 lists Coded Values referenced from the "Value" column of the tables above for <SR IOD1>:
[Document Coded Terms and Code Stringe values in the following table. Coded Terms must be documented as (Code Value, Coding Scheme Designator, "Code Meaning".]
Table N.9-50 defines the structure of the Basic Directory IOD.
Table N.9-50. Basic Directory IOD
Table N.9-51 defines the structure of <Private IOD 1>.
[Provide a list of all Modules, their presence, conditions in which they will be present and a reference to a table with the detailed module description. Below is an example for a Private IOD.]
[For <Private IODs> provide the list of shared Functional Group Macros and per-frame Functional Group Macros. Create one table for each supported Functional Group Macro using the structure defined below.]
The tables below list Private Modules and Attributes specific for <Private IOD 1>:
[List all IOD specific Modules in a separate table following the structure defined below, their Attributes, Values, usage, and conditions in the table below. For instructions on the content of the columns see instructions in SectionA.A Information Object Definitions (IODs).]
Table N.9-54 lists Coded Values referenced from the "Value" column of the tables above for <Private IOD 1>:
[Document Coded Terms and Code String values in the following table. Coded Terms must be documented as (Code Value, Coding Scheme Designator, "Code Meaning".]
[Note that the appendices defined in the following subsections are a mandatory part of the DICOM Conformance Statement and must be filled in by any product, that creates DICOM SR objects.]
[For each SR TID (including Private TIDs) that is created by the system (See Overview Section N.1.1.1) provide an Annex B.x.]
[If you are extending a TID by adding additional concepts indicate this extension by adding an asterisk to the TID number in the TID column (e.g.,4000*).]
[If your product creates SR Instances of a TID which includes long lists of measurements, they can also be documented in an external file. For details refer to the instructions right before Section N.10.2.]
This section provides the detailed content encoding for all TIDs supported by <product>.
Throughout the tables listed in Section N.10 the following codes are used for the "Source" and "Presence of Content Item" columns.
In the "Source" column, the following Values can be used:
CONFIGURATION: The Value is copied from the system configuration.
QUERY: The Value is determined by performing a query of any of the supported Query/Retrieve Services.
SCANNED: The Value is read from a barcode scanner or similar device.
SRC_INSTANCE: The Value is copied from previously created/received SOP Instances.
In the "Presence of Content Item" the following Values can be used:
ALWAYS: the module, functional group macro, Attributes or Value is always present.
CONDITIONAL: the presence of the module, functional group macro, Attributes or Value is dependent on a condition. The condition must be listed in the "Comments" column.
SRC_COPY: The presence of the Attributes and Values depends on the availability of these in the source instances, which are used for copying this information.
EMPTY: The Attribute is present but without a Value (zero length).
Table N.10-1 shows the encoding of content of a DICOM Mammography CAD SR (TID 4000).
[The following table shows how to document TID content usage, with TID 4000 as an example. Modify to match your product implementation, e.g., select supported concepts and Values and add additional templates as needed. In the "Value" column you can either list the coded Values directly, reference a CID from DICOM PS3.16 if used unmodified or provide a table in Section N.10.1.1, if you are using more than two codes (otherwise codes can be added directly to the table). For more complex TIDs it is possible to split the table below into multiple tables following the Template Structure defined in DICOM PS 3.16.]
Table N.10-4 shows the encoding of content of a DICOM Echocardiography Procedure Report (TID 5200).
[Table N.10-4 shows how to document TID content usage, with TID 5200 as an example." Modify to match your product implementation, e.g., select supported concepts and Values, and add additional templates as needed.]
Table N.10-4. Echocardiography Procedure Report SR (TID 5200)
|
One Container for each supported Finding Site, see Section N.10.2.1 |
||||||||
|
The following rows are supported for all Finding Sites listed in Section N.10.2.1. Values for supported concepts are listed in the "Modifier" column of the Tables in the respective subsections of Section N.10.2.1. |
||||||||
|
See Section N.10.2.1 for measurements and supported Modifiers for each Finding Site |
||||||||
The following Sections provide a list of measurements encoded for each Finding Site.
[Since the lists of measurements can be fairly extensive, they can either be provided in a separate excel sheet minimally providing columns for
[If you use an external document, state the following:]
Details about the supported measurements can be found at <link to external document>.
[If measurements are documented in this document, add for each supported Finding Site a subsection with all supported Measurements and their modifiers below following the examples shown.]
Table N.10-5 lists the measurements supported by <product>. The first column lists the label that is used on <products reporting screen>to select the respective measurements.
[Document all measurements supported on the product using the relevant measurements. Modify to match your product implementation, e.g., select supported concepts and Values, and add additional templates as needed. If private codes are used, indicate them through a 99_VENDOR_X Coding Scheme Designator, where VENDOR_X needs to be replaced with a vendor specific Value.]
[In the "Modifier" column list all supported modifiers by using the Concept Name Code from Table N.10-4 in Section N.10.2 and add a code for each Modifier Value.]
Table N.10-5. Left Ventricle Measurements
Table N.10-6 list the measurements supported by <product>. The first column lists the label that is used on <products reporting screen>to select the respective measurements.
Table N.10-6. Right Ventricle Measurements
[This section contains several subsections that describe information that may already be present in other security documents (e.g., MDS2 statement). For each subsection, you may fill it in or remove it and reference a separate security document if all information requested in this template is present in the separate referenced document.]
This section provides additional details about security features that are formally described in Section N.8.
[If your product is following RFC 8633, mention it here, otherwise describe what is implemented, e.g.:
[If this application supports the Basic Network Address Management profile as a DHCP Client, specify here how the DHCP Server is discovered.
If DNSSEC is supported (RFC 4033, RFC 4034, RFC 4035) for the interactions defined in Basic Network Address Management profile, describe the options supported here or provide a reference to the document describing them.]
Table N.11-1 defines the security patterns supported :
[Specify here which security pattern(s) your LDAP Client and/or LDAP Server implementation supports. Remove any actor not supported.]
[Indicate here how the product restricts remote access (User Access, Access per Patient, Access per Doctor). If this information is described in a separate document, provide the reference here instead.]
Table N.11-2 specifies the DICOM Audit Messages that <Product> can detect and report. It defines the list of triggers that will cause the Audit Message to be generated and if these triggers can be configured or not. It also specifies whether the content of the Audit Message can be configured or not.
[Indicate with Y (yes) or N (no) in the "Used" column to specify if your product supports the Audit Message. Then describe the list of triggers in the "Supported Triggers" column that make your product generate the Audit Message. Indicate with Y or N in the "Configurable Triggers" or "Configurable Message" columns whether these features are supported by your product.]
[The following part of this section can be either defined in the DCS or defined as a reference to a Service/Security Manual instead. In either case, all private messages will be described in addition to standard defined messages. As an example, the following table format may be used to describe these messages in this document.]
Table N.11-3 specifies the implementation details of each audit message supported by this product.
See Section N.6.6 Audit Trail Syslog Configuration for information about Syslog-TLS parameters.
See Section N.6.6 Audit Trail Syslog Configuration for information about Syslog-UDP parameters.
Table N.11.2.5-1 lists the secure transport connection profiles and cipher suites supported for TLS 1.3:
[Describe here the mechanisms and tools that are supported by the implementation for Certificate Distribution, Certificate Validation and Key Management.]
[In Table N.11.2.5-1 Secure Transport Connection Profiles and Cipher Suites, add any Profile claimed in Section N.8.4.2 Secure Transport Connection Profiles. For each Profile, list all TLS 1.3 Cipher suites supported by your product and fill in the "Default Preference Order" column if applicable.]
Table N.11.2.5-1. Secure Transport Connection Profiles and Cipher Suites
Table N.11.2.5-2 lists the secure transport connection profiles and key exchange algorithms supported for TLS 1.3:
[In Table N.11.2.5-2 Secure Transport Connection Profiles and TLS 1.3 Key Exchange Algorithms, add any Profile claimed in Section N.8.4.2 Secure Transport Connection Profiles. For each Profile, list all TLS 1.3 key exchange algorithms supported by your product and fill in the “Default Preference Order” column if applicable]
Table N.11.2.5-3 lists the secure transport connection profiles and signature algorithms supported for TLS 1.3:
[In Table N.11.2.5-3 Secure Transport Connection Profiles and TLS 1.3 Signature Algorithms, add any Profile claimed in Section N.8.4.2 Secure Transport Connection Profiles. For each Profile, list all TLS 1.3 signature algorithms supported by your product and fill in the “Default Preference Order” column if applicable]
Table N.11-4 lists the secure transport connection profiles and cipher suites supported for TLS 1.2:
[In Table N.11-4, add any Profile claimed in Section N.8.4.2 Secure Transport Connection Profiles. For each Profile, list all TLS 1.2 Cipher suites supported by your product and fill in the "Default Preference Order" column if applicable.]
Table N.11-4. Secure Transport Connection Profiles and Cipher Suites
[Describe here the mechanisms and tools that are supported by the implementation for Certificate Distribution, Certificate Validation and Key Management.]
Table N.11-5 describes the configurable parameters and behaviors supported by this product for the Secure Transport Connection:
[Indicated in the "Configurable" column whether the parameters are configurable (Y) or not (N).]
Table N.11-5. Secure Transport Connection Configuration
|
See Section N.6 Configuration |
|||
|
A-P-ABORT provider reason in case of integrity check failure |
|||
|
[List specific configurable parameters for the local system] |
|||
|
Modified BCP 195 RFC 8996 TLS Secure Transport Connection Parameters |
|||
|
[List specific configurable parameters for the local system] |
|||
|
See Section N.6 Configuration |
|||
|
A-P-ABORT provider reason in case of integrity check failure |
|||
|
[List specific configurable parameters for the local system] |
|||
|
Modified BCP 195 RFC 8996 TLS Secure Transport Connection Parameters |
|||
|
[List specific configurable parameters for the local system] |
|||
Table N.11-6 provides the list of Attributes and the action when de-identifying instances. Supported Action Codes are defined in PS 3.15 Section E.1.
[For every element listed in Table N.11-6, “De-identified Elements and Actions”, describe the Action the application may take using one of the actions codes defined below:]
D: replace with a non-zero length Value that may be a dummy Value and consistent with the VR
Z: replace with a zero-length Value, or a non-zero length Value that may be a dummy Value and consistent with the VR
K: keep (unchanged for non-sequence Attributes, cleaned for sequences)
C: clean, that is replace with Values of similar meaning known not to contain identifying information and consistent with the VR
U: replace with a non-zero length UID that is internally consistent within a set of Instances
Z/D: Z unless D is required to maintain IOD conformance (Type 2 versus Type 1)
X/Z: X unless Z is required to maintain IOD conformance (Type 3 versus Type 2)
X/D: X unless D is required to maintain IOD conformance (Type 3 versus Type 1)
X/Z/D: X unless Z or D is required to maintain IOD conformance (Type 3 versus Type 2 versus Type 1)
X/Z/U*: X unless Z or replacement of contained instance UIDs (U) is required to maintain IOD conformance (Type 3 versus Type 2 versus Type 1 sequences containing UID references)
[Indicated in the "Encrypted" column, whether encryption is supported. Y for yes, N for No.]
[Explain the scope here in which the application can ensure referential integrity of replacement Values for references such as SOP Instance UID, Frame of Reference UID, etc. if multiple SOP Instances are de-identified (e.g., across multiple Studies, consistent replacement if the same Study is processed more than once, etc.)
Also mention if Encrypted Attributes Data Set is to be used and which Transfer Syntaxes are supported for encoding/decoding the Encrypted Attributes Data Set.
Finally, list here any additional restrictions (e.g., key sizes for public keys).]
[Describe the Mapping of Attributes in this Annex, create a subsection for each mapping. Examples for such mappings are:
[The following subsection shows an example for the Mapping between Modality Worklist Instances and MPPS.]
Table N.12-1 describes the mapping of Attributes between Modality Worklist Instances and MPPS messages.
In the "Scenario" column the following Values are used:
[List the different scenarios which your product supports for mapping Attributes and use those Values in Table N.12-1 in the "Scenario" column. The list below represents an example that is derived from the IHE Radiology Technical Framework - Vol. 2; however, you can define your own scenarios or modify the list below. All entries in the list need to occur as permanent text in your DICOM Conformance Statement.]
SCHEDULED: The image acquisition was scheduled at the RIS and procedure details have been communicated in the MWL query)
UNSCHEDULED: The image acquisition was performed without Modality Worklist information
APPEND: Instances acquired are added to an existing study after the initial procedure was finalized
GROUP: Multiple requested procedures are grouped into one study.
In the "Value Source" columns, the following Values are used. The column cell may additionally contain an Attribute Tag if the value is copied from a different Attribute.
The "Destination" columns either contain TOP, if the Attribute is added to the top level Data Set of the Instance, or contain the Attribute Tag of the Sequence the Attribute will be added to. The "Comments" column can be used to provide additional information regarding the Values added to the Instance or MPPS.
[Update Table N.12-1 to match your product implementation. The entries in the table are meant as an example.]
Table N.12-1. Mapping of Attributes from Modality Worklist to Instance and MPPS